Transitioning from Momentics IDE to QNX Toolkit

QNX Toolkit1.1QNX Toolkit User's GuideDeveloperSetup

This section describes the differences between Momentics IDE and QNX Toolkit, including project structure, build system, debugging, and application packaging. It is intended to help you transition to using QNX Toolkit as your development environment. To learn how to migrate your projects from Momentics IDE to QNX Toolkit, go to Porting a Momentics IDE project.

Differences in project organization

One of the main differences that you will notice when launching VS Code is that the concept of the workspace is different. In Eclipse (and hence, Momentics IDE), you have a directory that stores all your projects, settings, and metadata; in VS Code, by contrast, the workspace is defined by a JSON file (<name>.code-workspace) that configures folders, workspace-specific settings, launch configurations, tasks, and extensions. The differences are illustrated in the diagrams shown below:

Eclipse:

Eclipse workspaces can contain multiple projects, and each project includes folders such as src, bin, and lib. Eclipse stores project-specific metadata in the .project and .classpath files, which define the project's type, build path, and other configurations.

Image of programs that run on host and target machines

VS Code:

In VS Code, user settings (often stored in specific user profiles) apply at the global level. These settings can also be customized for workspaces and workspace folders (for multi-root workspaces).

The following images show a typical Eclipse project structure comprised of projects and subfolders, as well as a VS Code multi-root workspace:


Eclipse	VS Code

Workspaces

In VS Code, a multi-root workspace is represented by a configuration file (.code-workspace) that stores settings and folder references. This is in contrast to Eclipse, which has a purely directory-based structure.

Workspace key differences:


Feature	Eclipse	VS Code
Folder vs. Config file	Workspaces are folder-based. A directory stores all your projects, settings, and metadata. When you launch Eclipse, you're prompted to select a workspace directory. Each workspace can have multiple projects, and you can switch between workspaces.	Workspaces are defined by a configuration file. You can create a workspace by saving a workspace (File > Save Workspace As) or creating a .code-workspace file.
Scope	Workspaces are rigidly defined.	Workspaces are flexible and can span multiple directories.
Settings	Workspaces store all global settings.	Global user settings are implemented above the level of the workspace. You can save multiple user profiles for greater flexibility.

Projects

Eclipse provides workspaces as a common area for grouping related projects, configurations, and settings. In VS Code, a "project" can be contained in a single workspace or span a multi-root workspace.

Project key differences:


Feature	Eclipse	VS Code
Structure	Includes specific folders like src for source code, bin for compiled classes, and lib for libraries. Project location is usually tied to workspace location. Stores project-specific metadata in files like .project and .classpath, which define the project's type, build path, and other configurations. Projects can have facets (e.g., Java, Web, Maven) that determine the project's functionality and tooling. Uses complex wizards to create or/and import projects.	Doesn't enforce a specific folder structure, allowing you to organize your code as needed. Uses configuration files like settings.json and launch.json to store settings and debug configurations specific to the folder in the .vscode sub-folder. Treats a folder as a workspace; you can open any folder as a workspace or add any folder to a multi-root workspace. No concept of project creation or import; you just open a folder and start coding.
Workspace relation	Workspace acts as default location where you create projects.	A VS Code workspace is not a directory, so there is no default location for project creation.

Note:

QNX Toolkit features a "default" directory associated with QNX projects, targets, and other information. The setting ID is qnx.config.defaultProjectsRoot. For more information, refer to QNX Toolkit Contribution Points.

Settings

VS Code provides different scopes for settings, including User settings (settings that apply globally), and workspace settings (settings that only apply when a workspace is opened). If you have a multi-root workspace, then you can configure settings on a per-folder basis.

Settings key differences:


Feature	Eclipse	VS Code
Levels of settings	Features two levels of settings: workspace and project. Stores settings in a .metadata folder within the workspace directory. Eclipse has a comprehensive preferences menu (Window > Preferences) where you can configure various settings such as editor behavior, compiler options, and plugin configurations. Some settings can be configured at the project level and stored in the .project or .settings folders.	Features a granular settings hierarchy with multiple layers: global, workspace, and folder. Stores global settings in a settings.json file, usually located in the user's profile directory. The profile allows you to store global settings separately, which is similar in concept to separate workspace settings in Eclipse. Allows you to override global settings for a specific workspace by putting settings in a .vscode/settings.json file within the workspace directory or inside the .code-workspace file. For a multi-folder workspace, VS Code allows you to override workspace settings with folder settings in .vscode/settings.json.
File-based vs. UI-based	Relies on a UI-based preferences menu.	Provides configuration through JSON files for greater flexibility.

Launch configurations

In both Eclipse and VS Code, a launch configuration is a set of instructions that tells VS Code how to run and debug your program.

Launch Configuration key differences:


Feature	Eclipse	VS Code
Configuration storage	Stores launch configurations in the workspace's .metadata directory or in the project's directory.	Stores launch configurations in a launch.json file, which is usually located in the workspace's .vscode directory. Can also be stored in a workspace file or as part of the global profile settings.
Configuration style	Provides a GUI for creating and managing launch configurations (Run > Run Configurations...).	Defines launch configurations in JSON format, allowing for transparent editing and version control.
Customization	Possible though cumbersome.	Both IDEs support customizable launch configurations, but VS Code's approach is more lightweight and flexible.

Build configurations

In both Eclipse and VS Code, a build configuration is a set of rules and settings that tell the build system how to compile, link, and package your code. In VS Code, build configurations are managed using tasks.

Build Configuration key differences:


Feature	Eclipse	VS Code
Storage	Stores build configurations in a complex, proprietary format, usually in the .project project configuration file.	Uses the .vscode/task.json file.
Configuration Style	Uses a GUI-based approach.	Uses JSON-based configuration files.

Feature parity

The following table illustrates how some well-known Momentics IDE features work in QNX Toolkit:


Feature	Momentics IDE	QNX Toolkit
C/C++ Development	QNX C/C++ Project properties	Requires C/C++ for Visual Studio Code extension. QNX Toolkit provides IntelliSense support for the C/C++ for Visual Studio Code extension; you can also customize IntelliSense.
Projects and Build	Developing Projects with the IDE	Provides out-of-the-box support for CMake and QNX Recursive Makefiles. For other build systems, manual configuration is required. Supports project templates and example projects. Supports auto-configuration of pre-existing projects.
Targets and Monitoring	Creating a target connection	Familiar experience creating target connections or virtual targets. Limited monitoring functionality. Support for remote filesystem operations. Support for target file transfer using launch configurations and tasks.
Debug and Run	Debugging Applications	Debugger functionality is similar. Refer to Launch configurations for more information. The following features require workaround: Debugging a core file. You can create a core file launch configuration using the C/C++ for Visual Studio Code extension. Disassembly. Available via GDB console. Other advanced features. Available via GDB console.
System Profiler	System Profiler	You can invoke tracelogger via direct command, launch configuration, or task configuration. For more information, refer to Initiating kernel logging. Limited functionality for viewing results.
BSP and image builders	Building a BSP	You can use the QNX Toolkit to build Board Support Packages (BSPs); for example, you can build a BSP for the Raspberry Pi 4 board. For more information, refer to Building a QNX SDP 8 BSP for Raspberry Pi.
Code coverage	Code coverage	Code coverage data can be viewed by using VS Code `gcov` extensions. For code coverage to work, you need to use your launch configuration to upload code coverage results to the host. For more information, refer to Remote filesystem operations.
Runtime analysis tools	Integrated tools	Valgrind data can be viewed by using VS Code extensions; you need to use your launch configuration to upload the data to the host. For more information, refer to Remote filesystem operations. QNX Memory Analysis. Currently there is no UI for showing the results. QNX Application Profiler. Currently there is no UI for showing the results.

Page updated: September 22, 2025