Home
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
Programming
Programmer's Guide
The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
Conventions for Recursive Makefiles and Directories
In this chapter, we'll look at the supplementary files used in the QNX OS development environment. Although we use the standard make command to create libraries and executables, we also use some of our own conventions in the Makefile syntax.
Structure of a multiplatform source tree

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
- Quickstart Guide
- System Architecture
  The System Architecture guide accompanies the QNX OS and is intended for both application developers and end-users.
- OS Components & Operations
- Graphics
- Programming
  - Getting Started with the QNX OS
    Getting Started with the QNX OS: A Guide for Realtime Programmers is intended to introduce you to the QNX OS and help you develop applications and resource managers for it.
  - Programmer's Guide
    The QNX OS Programmer's Guide covers a variety of topics that might interest developers who are building applications that will run under the QNX OS.
    - Compiling and Debugging
      Let's start by looking at some things you should consider when you start to write a program for the QNX OS.
    - QNX OS Architecture and Concepts
      The QNX OS architecture consists of the microkernel and several cooperating processes. These processes communicate with each other via various forms of interprocess communication (IPC). Message passing is the primary form of IPC in QNX OS.
    - Processes
      Your applications should be written in a way that reflects the architecture of the QNX OS—as a set of cooperating processes. In this chapter, we see how to start processes (also known as creating processes) from code, how to terminate them, and how to detect their termination.
    - Multicore Processing
      Multiprocessing systems, whether discrete or multicore, can greatly improve your applications' performance.
    - Working with Access Control Lists (ACLs)
      Some filesystems, such as the Power-Safe (fs-qnx6.so) filesystem, extend file permissions with Access Control Lists, which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards.
    - Understanding the Microkernel's Concept of Time
      Whether you're working with timers or simply getting the time of day, it's important that you understand how the OS works with time.
    - Handling Hardware Interrupts
      This chapter explains the QNX OS mechanisms for quickly reacting to hardware events.
    - Working with Memory
      (or The Persistence of Memory, with a nod to Salvador Dali) In the Process Manager chapter of the System Architecture guide, we looked at how the OS manages memory. This chapter describes how you can work with memory.
    - Freedom from Hardware and Platform Dependencies
      The QNX OS can run on many different hardware platforms. The way in which applications can access peripheral devices and how data is stored varies between platforms. This chapter explains our solutions for minimizing the impact of such platform dependencies.
    - Conventions for Recursive Makefiles and Directories
      In this chapter, we'll look at the supplementary files used in the QNX OS development environment. Although we use the standard make command to create libraries and executables, we also use some of our own conventions in the Makefile syntax.
      - Structure of a multiplatform source tree
        Makefile structure
        As mentioned earlier, the makefile structure is almost identical, regardless of the level that the makefile is found in. All makefiles (except the bottommost level) include the recurse.mk file and may set one or more macros.
        The recurse.mk file
        Macros
        The example given above uses the LATE_DIRS macro. Here, we list the macros that you can place within a makefile.
        Directory levels
        Let's look at the directory levels themselves in some detail.
      - Specifying options
      - Using the standard macros and include files
      - Advanced topics
      - Examples of creating Makefiles
        If you use our directory structure, you should use the addvariant command to create it. This section gives some examples of creating Makefiles for a single application, as well as for a library and an application.
    - Glossary
  - Writing a Resource Manager
- System Security Guide
  The QNX System Security Guide is intended for both system integrators who are responsible for the security of a QNX OS system and developers who want to create a QNX OS resource manager free from vulnerabilities.
- Utilities & Libraries
- Migrating to QNX OS 8.0
QNX Software in the Cloud
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Structure of a multiplatform source tree

QNX SDP8.0Programmer's GuideDeveloper

Here's a sample directory tree for a product that can be built for two different operating systems (QNX 4 and Neutrino), on two CPU platforms (x86_64 and ARM):

Figure showing a full source tree — Figure 1Source tree for a multiplatform project.

We'll talk about the names of the directory levels shortly. At each directory level is a Makefile file that the make utility uses to determine what to do in order to make the final executable.

However, if you examine the makefiles, you can see that most of them simply contain:

include recurse.mk

Why do we have makefiles at every level? Because make can recurse into the bottommost directory level (the variant level in the diagram). That's where the actual work of building the product occurs. This means that you could type make at the topmost directory, and it would go into all the subdirectories and compile everything. Or you could type make from a particular point in the tree, and it would compile only what's needed from that point down.

We'll discuss how to cause make to compile only certain parts of the source tree, even if invoked from the top of the tree, in the Performing partial builds section.

Note:

When deciding where to place source files, as a rule of thumb you should place them as high up in the directory tree as possible. This not only reduces the number of directory levels to traverse when looking for source, but also encourages you to develop source that's as generic as possible (i.e. that isn't specific to the OS, CPU, or board). Lower directory levels are reserved for more and more specific pieces of source code.

If you look at the source tree that we ship, you'll notice that we follow the directory structure defined above, but with a few shortcuts. We'll cover those shortcuts in the Advanced Topics section.

Page updated: August 09, 2024