1) If you are using Makefile Projects simply call make from project directory, you have to create a super makefile to build all required projects (can create a super project for that too)
2) Using of container projects. This option could be convenient for those who use a big code base. Container is a holder of various projects (among them could be other containers as well). It is the user's decision on how to combine projects into container. For example, third-party service libraries could be assembled in a single container. Each container has a set of different build configurations (this is almost the same as assigning make targets such as debug, release etc.). To build the whole workspace just launch a root container build specifying configuration. This structure should be mirrored into command line build. To provide this, insert special make file into top container's root directory The content looks like that:
<configuration_1> :
cd ../Child_Container_1 ; make <target name>
cd ..
...
cd ../Child_Project_k ; make <target name>
...
<configuration_n> :
...
3) Using mksbp utility
4) Using make for QNX Projects. In this case super makefile has to contain some setup which includes setting "project path" macros. The recommended way is to create an extra file with this definition (here mylib is the project name):
(repeat this for every project)
Then add to this extra make file launch of you "root" make file or add environment variable MAKEFILE=<extra-makefile>.
If you build several IDE project you have to create an additional makefile (can be the same as one with variables) and call make in every project, i.e.
PROJECT_ROOT_mylib=F:/libs/mylib
PROJECT_ROOT_myapp=F:/libs/myapp
all:
cd ${PROJECT_ROOT_mylib}; make all
cd ${PROJECT_ROOT_myapp}; make all
QNX QCC toolchain set environment variables, such as CC, LD etc. They are automatically corrected when you switch compiler or build variant from Settings page of project properties. If you don't want these variables to be defined you can select and undefine them from the Environment tab.
Managed C project (MBS) with QNX toolchain can be used in similar way as QNX Project. They are both managed projects. QNX Project is based on qnx recursive makefiles, when you change setting of QNX Project you modifying a makefile for this project. If you change makefile manually - QNX Project would read and recognize this change (it may be limited to known build macros). Managed project stores all setting in XML and they cannot be changed outside of IDE. You can pick builder for Managed project - internal builder, or external make builder. In the second case, makefiles would be generated that represent build process for this project, but you cannot change those makefiles. Besides that, MBS has a bit more modern UI and more flexibility for project structure (you can exclude some files to be compiled for example). On the other hand QNX Project has very good build variants structure which is nice when you are building for 5 platforms at the same time.
See the technical article, "Projects, Building, and the IDE".
QNX Project properties are mostly stored directly in makefiles, in particular "common.mk". Additional macro and functions stored in internal makefile ".qnx_internal.mk". Settings for current active builds are stored in workspace metadata, outside of the project. If you want it to be stored with project you can check "Share all project properties" - in this case it would be stored in .cproject file inside the project folder.
Yes, QNX IDE is based on Eclipse CDT which allow to create project for any target. You need to install appropriate toolchain on your host and you may need to create a toolchain definition from IDE. Search CDT newsgroup for this topic.
To enable QNX Toolchain as preferred toolchain for Makefile and Managed projects: * Open Window->Preferences...
If you are anticipating creating many new projects and they will have values different than the defaults, you can change default settings for makefile projects:
For Qnx Projects:
To fast access to Build command define a keyboard shortcut (e.g. F6).
To show build button in C/C++ perspective (or any other perspective) from bar menu select "Windows->Customize Perspective->Commands" and check "Build Action Set".
By default you have several platform configurations, for each of them you have release and debug variant. You can create extra configurations for example to link with different libraries. Lets say you want configuration 1 link with library libMy1.so and configuration2 link with library libMy2.so. To do that first select you platform, for example x86 (In Project->Properties...->QNX C/C++ Project->Build Variants). You have "debug" and "release" inside. Add "release2" and "debug2" (by selecting "x86" and pressing Add button on the right). Click on "Advanced" button at the bottom. ON the top right select x86 and "release", in library tab pick Extra Libraries from pull-down menu and add your library libMy1.so. Same for debug. Same for release2 and debug2 but pick library libMy2.so this time. When you build you now would have 4 configurations.
The IDE wants you to narrow down the scope of what it needs to know about (source, binaries etc) so you need to create a project _associated_ with your source/binaries and this project is in turn _associated_ with a workspace. This project doesn't have to be in the workspace, it can be anywhere you want it to be. Here are some options:
See more on this topic in Project, Build and IDE Article.
The process of selecting a project type appears more complicated than it is. For _nearly_ every type of existing code with a build process, you will want to choose the "Makefile Project" type. Why? Because this project type just calls out to some external build program to build the source. Most of the time this is 'make', hence the name of the project, but it could be JAM, ANT, dmake, cons or any other builder.
If you have the luxury of starting your project from scratch, then the QNX Projects are interesting because they allow you to build multiple processors (more generally 'variants', including OS'es) with a single build based on the QNX recursive make framework. They won't 'port' well to other systems however. Managed Make Projects are interesting because they provide a full IDE graphical control and configuration, familiar to those coming from Visual Studio, and can really take advantage of the Eclipse frameowork (ie incremental compiles, links etc) but are still relatively immature.
... and if you are never going to run your build from the IDE (I never say never), then the choice is even simpler: Standard Make all the time just to identify the source as "C/C++" source and help identify the binary types. See more on this topic in Project, Build and IDE Article.
Since one of the goals of the IDE is to simplify and automate work for developers, it needs to be told what to do, there are two (per project and global default) settings in particular that are important: