QNX C/C++ Project properties

Note: In past releases, such projects were called simply QNX Projects. Because this term is vague and the preferred choice is to use standard (non-recursive) makefiles, these projects are now called QNX Legacy Recursive Make projects. This term is used in the QNX Project wizard.

When you're creating QNX Legacy Recursive Make projects, the QNX Project wizard exposes some of the build settings in its Project Settings dialog, allowing you to configure the new project. After you've created the project, you can access the QNX C/C++ Project properties to edit those same build settings and define new ones. For instance, you can add include paths to your project through the Compiler tab and libraries through the Linker tab; both tabs are shown only in the properties dialog (not the wizard). Also, you can enable code coverage through the Options tab.

You can access the QNX C/C++ Project properties in two ways:

by left-clicking a project entry in the Project Explorer, choosing Project > Properties from the main menu area, then selecting QNX C/C++ Project on the left in the resulting window
by right-clicking a project entry, choosing Properties in the context menu, then selecting QNX C/C++ Project on the left in the resulting window

Options

The Options tab contains these fields:

Category	Name	Description
General Options	Share all project properties	Whether to share all of your project's properties with other developers. By default, some properties (e.g., active targets) are local, meaning they're stored in the .metadata folder in your own workspace. If you check this box to enable sharing of all properties, the IDE then stores them in a .cproject file, which you can save in your version control system so that others may access that file.
Build Options	Build for Profiling (Call Count Instrumentation)	Makes the IDE insert code at the beginning of each function, to track how many times it's called and who calls it. After building an application with this option enabled, you can use the Application Profiler to collect statistics about call counts and callers.
Build Options	Build for Profiling (Function Instrumentation)	Makes the IDE insert code just after the entrance to and just before the exit from each function, to measure its total runtime. After building an application with this option enabled, you can use the Application Profiler to determine how much time is spent in each function and in its descendants (i.e., functions that it calls).
Build Options	Build with Code Coverage	Builds the project for code coverage, which makes the IDE insert code that counts the execution of basic blocks as well as generate notes (.gcno) files that map block count data to individual lines of code. When you then run an application with the Code Coverage tool, the IDE visually presents line-by-line coverage data.

Build Variants

This tab specifies the processor architectures and build variants to generate binaries for. In the list area, you can expand the architecture categories to see and enable specific variants.

Note: Initially, none of the variants is enabled, but you must select at least one variant when creating the project. If you want any build variants to be auto-selected for new projects, you can change the default preferences for the legacy QNX project type. To do so, open Windows > Preferences > QNX > New Project > Build Variants.

You can click the Select All button on the right of the list area to enable all of the listed variants, or the Deselect All button to disable all of them. After selecting an architecture in the list, you can click Add to add a new build variant; for example, you could create a build variant for unit testing. To remove a variant that you defined, select it in the list, then click Delete. Note that you can't remove the debug and release variants.

For each architecture, you can choose one build variant to be the “indexer”, by clicking that variant and then the Set Indexer Variant button. This variant's symbols and include paths will then be used for source indexing. The impact on the C/C++ Editor is that the source indexing determines the macro definitions, inclusion/exclusion of additional code, the navigation to header files, and more.

Library

This tab is shown only for libraries, not standalone applications. In the QNX Project wizard, you must select the project type in the Basic Settings. If you choose any type other than Application, you'll see the Library tab in the QNX C/C++ Project properties after you've created the project.

The Build target type radio buttons let you select the kind of libraries to build. You can choose from these options:

Static library

Combines the object files into an archive (libxx.a) that can be directly linked into executable programs. A static library is a collection of object files that you can add to applications.

Shared library

Combines binary objects and joins them so they're relocatable and can be shared by many processes. The shared object (libxx.so) is an executable module that gets compiled and linked separately. Select this option if:

you have code to reuse
you want to generate a library that will be relocated (copied) to a target machine
you want to statically link code into a shared object

When you create an application that uses a shared library, you must define your shared library's project as a Project Reference for your application.

If you choose to use versioning (in the General Options of the Linker tab), two files are generated for a shared library: libxx.so and libxx.so.n, where n is a version number with a default of 1. The first file is a symbolic link to the latest version of the second file. If you don't use versioning, only one file (libxx.so) is generated.

The IDE also generates a static shared library (libxxS.a). This is a collection of objects compiled to be position-independent. The static shared library lets you build custom shared libraries that use a subset of the objects from the original library, so you can remove unused functionality and thus, reduce the overhead of the library.

Shared+Static library

Creates every kind of library that exports its symbols. This is the same as selecting Static+Static shared library (see the next option), except that the IDE also builds a shared object (libxx.so).

Static+Static shared library

Generates two types of static libraries: A static library (libxx.a), which is meant for linking into executable programs, and a static shared library (libxxS.a), which has position-independent code (PIC) and is meant for linking into shared objects.

Shared library without export

Generates a shared library without versioning. This is useful for applications to discover functionality extensions at runtime (e.g., driver modules that plug into hardware). Generally, you write code to open the library with dlopen() and to locate specific functions with dlsym().

General

This tab defines the following basic properties:

Name	Description
Installation directory	The directory where the make install process copies the binaries that it builds.
Target base name	The base name for the library or executable being built. This is the filename section between the lib prefix (for a library) and the extension delimiter (`.`). Typically, this is suffixed by patterns such as _g for debug, or _foo for a variant named `foo`, and so on. For more information about recursive makefile naming, see the Conventions for Recursive Makefiles and Directories chapter in the Programmer's Guide.
Use file name	The name of the usemsg file that puts the use message into the binary file. The message is kept in a header, and the usemsg command looks for this header to print the message.

Compiler

The Compiler tab contains these fields:

Category	Name	Description
General Options	Compiler	The compiler type. This field is read-only if the SDP installation that you're using has only one compiler installed. SDP 7 ships with only one compiler, with a type of GNU Compiler Collection (4.7.3). If you're using an SDP setup with multiple compilers, you can select from among multiple options. When you change the SDK selection to build programs with another SDP version, the options in the Compiler dropdown are updated based on that new selection.
General Options	Warning Level	Set the warning level threshold, which can be: `Default` — use the compiler's default warning level `Suppress` — don't output any warnings; equivalent to level 0 `1` to `9` — output warnings at or above this level
General Options	Generate Preprocessor Output	Makes the preprocessor write out intermediate code for each source file. The output file is named `source_file`.i (for C) or `source_file`.ii (for C++).
General Options	Optimization Level	The optimization level of the binary, either Default (which is level 2 for qcc or a number from 0 (no optimization) to 3 (most optimization).
General Options	Dependency checking	Makes the preprocessor write out a dependency map for each header file. The output file is named `source_file`.d. You can check dependencies and generate maps for user headers only or for all headers.
General Options	Debug Symbols	Whether to generate debug symbols. This field is read-only in Regular mode and has Default selected, meaning that the inclusion of debug information in the outputted binary depends on the build variant. If you switch to Advanced mode, you can override this setting for some build variants, by selecting With Debug Symbols. This ensures that debug symbols are written into the binary, even if they normally aren't for that variant.
General Options	Macro Definitions	Provides a list of symbol definitions to pass to the compiler using the command-line option -D `name`[=`value`]. You don't need to type the -D; the IDE adds it automatically.
General Options	Other Options	Provides any other command-line options not already covered in the Compiler tab. For details about all compiler options, see the qcc entry in the Utilities Reference.
General Options	All Compiler Options (CCFLAGS)	Displays all command-line options (flags) that will be passed to the compiler based on the settings in other fields.
Include Paths	Include import directories	A list of directories telling the compiler where to look for included files. You must add to the list any directory containing a user header file referred to by an `#include` statement. On the right, there are three buttons that open file selectors so you can add directory entries: Workspace — Browses the workspace projects. The IDE uses relocatable notation, so even if other team members use different workspace locations, you can all work successfully without any additional project adjustments. QNX Target — Starts browsing at the directory defined by the QNX_TARGET environment variable, allowing you to pick a directory from this area of the host filesystem. File System — Lets you pick any directory on your host machine. Below this, the Delete button lets you delete entries and the Up and Down buttons let you change the order in which the include paths are searched. The order is important when multiple header files have the same name.
Extra Source Paths	Source import directories	A list of directories telling the compiler where to find source code (which is needed for displaying debug symbols) in locations other than the project root directory. The controls are the same as for Include import directories—you can add entries from the workspace, QNX_TARGET directory area, or local filesystem, you can delete entries, and you can adjust their order.

Linker

The Linker tab contains these fields:

Category	Name	Description
General Options	Generate map file	Whether to print a link map to the build console.
General Options	Stack Size	The stack size, in bytes or kilobytes. For kilobytes, you must put a `K` at the end. The number is specified in decimal.
General Options	Export Symbols	Defines the level of final stripping done by the linker for your binary. This can be the default setting or it can range from exporting all symbols, to removing only the debug symbols, to removing all symbols.
General Options	Artifact Name	The name of the binary file generated for your project. By default, an application executable has the same name as the project from which it's built; you must fill in this field to give the artifact another name. A library file has prefix of lib and an extension of .a or .so, depending on the type of library. The base name, which is in-between, contains the name given in this field (or the project name if the field is blank). Debug variants of application and library binaries have the _g suffix in the filename, just before the extension.
General Options	Link against CPP library	(for QNX C++ projects only) Default — The standard QNX C++ library, with support for all standard C++ features (exceptions, STL, etc.) LLVM with exceptions — The LLVM C++ library, with support for exceptions GNU with exceptions — The GNU G++ Standard Library, with support for exceptions
General Options	Shared Library Name	(for build target types that generate a shared object (.so) library file) Sets the internal name (SONAME) of the shared object. This setting doesn't affect the actual filename. Defining an SONAME allows applications to determine which library version they're dynamically linking to, as explained in “Specifying an internal name” in the Programmer's Guide.
General Options	Shared Library Version	(for build target types that generate a shared object (.so) library file) Sets the version number for both the internal name (SONAME) and the filename of the shared object. If the library doesn't have a version number (e.g., its filename is to be lib`xx`.so with no numeric suffix), select No. This way, the shared-object name isn't hard-coded in the library. To use versioning, you can leave the field setting as `Default`, in which case the IDE uses 1 as the version number, or select an exact version number within the available range. The filename is then lib`xx`.so.`n`, where `n` is a number based on this setting. Also, the SONAME ends with so.`n`. The loader requires the filename to be exactly like this because all dependent projects will refer to the library as so.`n` (in the `NEEDED` section of the executable).
General Options	Other Options	Provides any command-line options not already covered in the Linker tab. For details about linker options, see the qcc entry in the Utilities Reference.
General Options	All Linker Options (LDFLAGS)	Displays all command-line options (flags) that will be passed to the linker based on the settings in other fields.
Libraries		The libraries to link to your project. Each library entry has three fields: Name — The base name, which is the filename part without the lib prefix (which the linker adds automatically) or the extension (.a or .so) Type — The library type, one of Static, Dynamic, Stat+Dyn, or Dyn+Stat Match build variant — Whether the linker looks for a library version that matches the final binary's version. When `Yes`, the library name format must match that of the artifact being built based on whether the _g suffix is present. For instance, if you want to build a release binary version that uses a debug library version, you must set this field to `No`. On the right, the Add button creates a new entry, in which you must fill in the fields manually. The two buttons just below open file selectors so you can automatically fill in the fields by selecting a library file: Workspace — Browses the workspace projects. The IDE uses relocatable notation, so even if other team members use different workspace locations, you can all work successfully without any additional project adjustments. QNX Target — Starts browsing at the directory defined by QNX_TARGET, allowing you to pick a directory from this area of the host filesystem. Below this, the Delete button lets you delete entries and the Up and Down buttons let you change the order in which the libraries are processed. If a static library references symbols defined in another static library, the library containing the reference must be listed before the one containing the definition. If you have cross or circular references, you might not be able to satisfy this requirement.
Libraries Path	Library directory expression	A list of directories telling the linker where to look for library files. This list must contain any directory storing an archive (.a file) or shared object (.so file) that implements library functions called by your project code. When you add an entry to the Library list, the library's path is automatically added to the Libraries Path list. However, deleting an entry from the first list doesn't delete it from the second one. You can explicitly add library paths by using the Workspace and QNX Target buttons, which behave the same as for the Library field. Meanwhile, the File System button lets you pick any host directory. The Delete, Up, and Down buttons also behave the same way.
Extra Object Files	Extra objects or libraries	The extra object or library files to link with your project. You can't manually fill in an entry but you can click the Workspace, QNX Target, and File System buttons to pick a file through a file selector. These buttons behave the same way as they do for Libraries. The remaining buttons are also the same—you can delete entries and adjust their order in the list. Note: The file selector may seem slow when adding files. This is because the IDE can't make assumptions about naming conventions, so it must inspect a file to determine if it's an object file or library.
Post-build Actions	Commands	Specifies commands to run after building the project. These commands are run sequentially, in the order listed in this field. If you click Add, the resulting dialog asks you to pick from four categories: Copy result, Move result, Rename result, and Other command. For the first three categories, additional fields let you specify what component you want to copy, move, or rename, and the destination or new name. For the last category, you must enter the command string in an extra field. You can remove a command with Delete and change the command order with Up and Down.

Make Builder

The Make Builder tab exposes these fields:

Category	Name	Description
Build Command	Use default	Whether the default make command is used for building your project.
Build Command	Build command	Defines a custom build command. It could be a make command with customized arguments or an invocation of another utility. In the latter case, you must provide the path of the build utility. This field is editable when Use default is unchecked. On the right, you can click Variables to open a window that displays make variables and allows you to pick one variable and provide an argument for it. The required string token is then added to the make command when you close this window.
Build Settings	Stop on first build error	Whether you want the IDE to stop building as soon as it encounters a make or compile error.
Workbench Build Behavior	Build on resource save (Auto Build)	After you check the box, you can change the name of the auto-build target, using the text field. Clicking Variables opens the same window used for Build command, so you can use variables in the target name.
Workbench Build Behavior	Build (Incremental Build)	The checkbox enables the text field so you can change the name of the target for incremental builds. The Variables button lets you add variables to the name.
Workbench Build Behavior	Clean	The checkbox enables the text field so you can change the name of the target for cleaning. The Variables button lets you add variables to the name.
Build Location	Build directory	Defines the directory from which your project is built. By default, this field is blank, which means that the project root directory is used. You can enter a relative path in the workspace or click the Workspace button to select a path from the workspace. The File System button lets you pick any host directory, while Variables lets you add variables to the directory name.
Parallel Build Setting	Use parallel jobs	Enables parallelism in building, which reduces the build time but increases memory usage.
Parallel Build Setting	Parallel job number	The maximum number of parallel build jobs to allow. There's a limit on how much parallelism the IDE can achieve when building; this limit depends on many characteristics of your project, including interproject dependencies.

Error Parsers

In this tab, you can select the build output parsers to apply to the project and specify in what order to apply them. The output parsers scan the build results for error, warning, and information messages and generate problem markers, which visually indicate problems in views such as Console and Problems.

The Error Parsers tab lists all supported parsers and provides checkboxes for selecting or unselecting them, as well as the Up and Down buttons to change the application order for the parsers. There are also Select All and Unselect All buttons, for convenience.

Regular and Advanced modes

The QNX C/C++ Project properties dialog can appear in two different modes: regular and advanced. Regular mode lets you configure build settings at the project level; usually, this offers a sufficient level of control. But you can switch to advanced mode to override certain settings for particular build variants.

To switch modes, click the Regular or Advanced button at the bottom of the dialog (the button shown is for the mode currently not displayed). For new projects, the regular mode is displayed initially, but the IDE remembers your mode setting so it reuses the last mode whenever you reopen the dialog.

In advanced mode, the properties dialog displays an additional panel between the left-side navigation and the properties tabs. In this extra panel, the Platform and Variant dropdowns let you choose an architecture and build variant for which you can override some settings. When you select from both these dropdowns, the display is filtered to show only the Compiler and Linker tabs. The settings that you can override include but aren't limited to:

Warning Level
Optimization Level
Debug Symbols
Libraries or Library Paths