Caution: This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.

IDE Concepts

In this chapter:

What is an IDE?

Welcome to the Integrated Development Environment (IDE), a powerful set of tools in the QNX Momentics Tool Suite. The IDE is based on the Eclipse Platform developed by Eclipse.org, an open consortium of tools vendors (including QNX Software Systems).

The IDE incorporates into the Eclipse framework several QNX-specific plugins designed for building projects for target systems running the QNX Neutrino RTOS. The tools suite provides a single, consistent, integrated environment, regardless of the host platform you're using (Windows or Linux). Plugins from most vendors should work within the Eclipse framework in the same way.

An IDE for building embedded systems

The IDE provides a coherent, easy-to-use work environment for building your applications. If you've used an IDE before, then you already have a good idea of the convenience and power this kind of toolset can offer.

Through a set of related windows, the IDE presents various ways of viewing and working with all the components that comprise your system. In terms of the tasks you can perform, the toolset lets you:


Note: The IDE doesn't require that you abandon the standard QNX Neutrino tools and Makefile structure. On the contrary, it relies on those tools. If you continue to build programs at the command line, you can also benefit from the IDE's unique and powerful tools, such as the QNX System Analysis tool and the QNX System Profiler, which can literally show you, in dynamic, graphical ways, exactly what your system is doing.

Perspectives

A perspective is a task-oriented arrangement of the workbench window.

For example, if you're debugging, you can use the preconfigured Debug perspective, which sets up the IDE to show all the tools related to debugging. If you want to work with the elements and tools related to profiling, open the QNX Application Profiler perspective.

You can customize a perspective by adding or removing elements. For example, if you want to have certain profiling tools available whenever you're debugging, you can add those elements to the Debug perspective.

Perspectives generally consist of these components:

Perspectives govern which views appear on your workbench. For example, when you're in the Debug perspective, the following main views are available (in the default configuration):

Views and editors

Views

Views organize information in various convenient ways. For example, the Outline view shows you a list of all the function names when you're editing a C file in the C/C++ editor. The Outline view is dynamic; if you declare a function called mynewfunc(), the Outline view immediately lists the function.

Views give you different presentations of your resources. For example, the Navigator view shows the resources (projects, folders, files) you're working on. Like individual panes in a large window, views let you see different aspects of your entire set of resources.

Views provide:

Editors

You use editors to browse or change the content of your files. Each editor in the IDE is designed for working with a specific type of file. The editor that you'll likely use most often is the C/C++ editor.

The editor area is a section of the workbench window reserved for editors. Views can be anywhere on the workbench, except in the editor area.

The IDE lets you rearrange views and editors so they're beside each other (tiled), or stacked on top of each other (tabbed).


Note:

Using an alternate editor: You can use a text editor other than the one included with the IDE; however, you will lose the integration of the various views and perspectives. For example, within the text editor of the IDE, you can:

  • set breakpoints and then see them in the Breakpoints view
  • assign “to-do” markers on particular lines and see them in the Tasks view
  • obtain context sensitive help as you pause your cursor over a function name in your code

For more information about the features of the text editor included with the IDE, see Concepts-->Editors and Reference-->Preferences-->Text Editors in the Workbench User's Guide.

To use an alternate editor, we recommend that you:

  1. Edit your files outside of the IDE.
  2. Ensure that you save your files in the correct workspace location. For example, on Windows configurations, you might use the following location:

    C:/ide-4.6-workspace/project_name

  3. To refresh the resources, from within the IDE, use the Refresh command (right-click menu in the Navigator view or the C/C++ Projects view).

Projects and workspace

Projects are generic containers for your source code, Makefiles, and binaries. Before you perform any work in the IDE, you must first create projects to store your work. One of the more common projects is a QNX C/C++ Project.


Note: Throughout this guide, we use the term “C/C++” as shorthand to cover both C and C++ projects; however, the titles of elements within the IDE itself are often explicit (e.g. “QNX C Project,” “QNX C++ Project,” etc.).

When you create a file within a project, the IDE also creates a record (local history) of every time you change that file, and how you change it.


Note: The location of the IDE error log file is $HOME/ide-4.6-workspace/.metadata/.log. To view the error log from within the IDE, select Help-->About QNX Momentics IDE, click Configuration Details, and then click Error Log.

Your workspace is a folder where you keep your projects. For the exact location of your workspace folder on your particular host, see Where Files Are Stored appendix in this guide.


Note:

All files must belong to a project, and consequently you can't open an arbitrary file in the filesystem; files have to be a part of some project (you work on a known set or resources).

For Windows, dragging and dropping files to the Navigator works as long as the destination is a project or folder. Once in the workspace, double-click to open the appropriate editor.


Considerations for project development

What is the difference between the project types?
The IDE has these project types:
How portable are the project types?
The metadata files that should be stored with the project in source control are:

Note: Metadata (also referred to as workspace/.metadata) should never be stored in source control.

Are projects portable between different versions of the IDE?
Projects are portable between different versions of the IDE; however, see the Release Notes for any known issues regarding the import process.
For an existing project without metadata, what's the best method to import it into the IDE?
To import an existing project into the IDE, use the Import wizard (File-->Import…). Alternately, you can create a link folder; however, the IDE won't copy any of its source code.
How should complex development scenarios be organized?
Typically, you want to organize your projects such that there is one binary/shared library per project (including all multiplatform and debug variants).
How do different projects in the same workspace interact?
You can add a dependency that can affect the build and make dependencies. Typically, you want to add an explicit dependency on particular types, such as shared libraries.
Can more than one executable be created in the same project?
If you use a Standard make project, you can create more than one executable for the same project.

Specifying a workspace location

To redirect the IDE to reference different workspaces:
From the directory where the qde.exe executable (Windows) or the qde script (all other hosts) resides, run the following command:
./qde -data path_to_workspace

where path_to_workspace is the location of your working directory.

This command launches the IDE and specifies where you want the IDE to create (or look for) the workspace folder.


Note:

Don't use spaces when naming a project or file; they might cause problems with some tools, such as the make utility.

For Unix-type hosts (such as Linux), filenames are case-sensitive, but for Windows they're not. For this reason, don't use case alone to distinguish files and projects. For example, Hello.c and hello.c refer to the same file in Windows, but they're two separate files for a Unix-type system.


How the IDE characterizes projects using natures

The IDE associates projects with natures that define the characteristics of a given project. For example, a Standard Make C Project has a “C nature,” whereas a QNX C Project has a C nature as well as a QNX C nature, and so on.


Note:

QNX C or C++ projects use the QNX recursive Makefile hierarchy to support multiple target architectures; Standard Make C/C++ projects don't.

For more information about the QNX recursive Makefile hierarchy, see the Conventions for Recursive Makefiles and Directories chapter in the Neutrino Programmer's Guide.


The natures inform the IDE what can and can't be done with each project. The IDE also uses the natures to filter out projects that would be irrelevant in certain contexts (for example, a list of QNX System Builder projects won't contain any C++ library projects).

The following table contains the most common projects and their associated natures:

Project Associated natures
Simple Project None
C Project C
C++ Project C, C++
QNX C Project C, QNX C
QNX C Library Project C, QNX C
QNX C++ Project C, C++, QNX C
QNX C++ Library Project C, C++, QNX C
QNX System Builder Project QNX System Builder

The IDE saves these natures and other information in the files called .project and .cdtproject in each project. To ensure that these natures persist in your source control system, such as CVS or SVN, include these files when you commit the project.


Note: The IDE doesn't directly support nested projects; each project must be organized as a discrete entity. However, the IDE does support project dependencies by allowing a project to reference other projects that reside in your workspace. Container projects also let you logically nest projects by collecting several projects together.

Host and target machines

The host is the computer where the IDE resides (e.g. Windows). The target is the computer where QNX Neutrino and your program run.

Target agent (the qconn daemon)

The qconn daemon is the target agent written specifically to support the IDE. It facilitates communication between the host and target computers.

For more information about connection methods, see the Launch Configurations Reference chapter in this guide.

Launcher

Before you can run a program, you must tell the launcher of the IDE what program to run, the target to run it on, the arguments to pass to the program, and so on.

If you want to run the program on another target or run with different options (e.g. with profiling enabled), you must create a new launch configuration or copy a previous one and modify it, as required.

Resources

Resources is a collective term for your projects, folders, and files.

Wizards

Wizards guide you through a sequence of tasks. For example, to create a QNX C Project, you run a wizard that guides you through all of the steps to gather required information before creating a project. For more information about wizards, see the Common Wizards Reference chapter in this guide.

Keyboard shortcuts

You'll find many keyboard shortcuts for various UI tasks throughout the IDE. For instructions about creating your own shortcuts, follow these links in the Workbench User Guide:

Reference-->Preferences-->Keys


Note: Some existing shortcuts and some commands that can be assigned to shortcuts apply only to Java code and projects. For example, the “Search for Declaration in Workspace” command, which is bound to Ctrl-G, works only with Java code.

Version coexistence

You can have a QNX Software Development Platform version 6.4.1 installed on the same machine as QNX Momentics 6.3.x and 6.2.x; however, the IDE installed with version 6.4.1 doesn't necessarily work with the tool chains from these earlier releases.

For more information about coexistence, see Coexistence in the Migrating from Earlier Releases appendix.

When you install the QNX Momentics Software Development Platform, you receive a set of configuration files that indicate where you've installed the software. The QNX_CONFIGURATION environment variable stores the location of the configuration files for the installed versions of Neutrino.

QWinCfg for Windows hosts

On Windows hosts, because of coexistence issues, you can't use the configuration program (QWinCfg) that lets you change versions of the QNX Momentics Tool Suite for the IDE.

qconfig utility for non-Windows hosts

The qconfig utility lets you configure your computer to use a specific version of Neutrino:


Note: In the previous example, notice that you must use the “back tick” character (`), not the single quote character (').

When the IDE starts, it uses your current qconfig choice as the default version of the operating system. If you haven't specified a version, the IDE chooses an entry from the directory identified by QNX_CONFIGURATION environment variable. If you want to override the IDE, choose an appropriate build target.

Coexistence and PhAB

If you're going to create Photon applications for QNX Neutrino 6.4.1 using PhAB, you need to use the older version of PhAB to create your application resources.

To ensure that you're always using the older version of PhAB to create your resources:

  1. Choose Window-->Preferences from the menu to display the Preferences dialog.
  2. Expand the QNX item in the list, then choose Appbuilder to display the Appbuilder preferences:

    PhAB preferences

  3. Clear the Use default check box.
  4. Change the Path to Photon Appbuilder to C:/QNX641/host/win32/x86/usr/bin/appbuilder.bat.
  5. Click OK to save your changes and close the Preferences dialog.

Specifying which OS version to build for

To specify which version of Neutrino you want the IDE to build for:

  1. Open the Preferences dialog (Window-->Preferences).
  2. Select QNX.
  3. From the Select Install list, select the OS version you want to build for.
  4. Click Apply, then click OK.

Environment variables

Neutrino uses these environment variables to locate files on the host computer:

QNX_HOST
The location of host-specific files.
QNX_TARGET
The location of target backends on the host machine.
QNX_CONFIGURATION
The location of the qconfig configuration files.
MAKEFLAGS
The location of included *.mk files.
TMPDIR
A directory used for temporary files. The gcc compiler uses temporary files for the output of one stage of compilation used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper.

The qconfig utility sets these variables according to the version of the QNX Momentics Tool Suite that you specified.