QNX Makefile

As part of the QNX development environment, QNX provides its own convention for defining a Makefile project, which a developer can use by sourcing the toolchain for the SDP. Refer to the "Conventions for Recursive Makefiles and Directories" documentation in the Programmer's Guide for more information.

QNX Makefile projects typically include a common.mk file with definitions applicable across all of its variants. Files like common.mk can be automatically generated by the addvariant utility. The common.mk file has the format:

ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)

# Name of the resulting binary file
NAME=

# Description for the use command
define PINFO
PINFO DESCRIPTION=
endef
# Location of the file containing the use message
USEFILE=

# Build definitions
#SRCS+=
#LIBS+=
#CPPFLAGS+=
#LDFLAGS+=
#...

include $(MKFILES_ROOT)/qtargets.mk

Then, the QNX Makefile projects must use a specific file structure containing a Makefile on each level. This lets the make program find the variant directories to use as the root directory for the build. To simply create individual variant build directories in the same place as the common.mk file, first create a Makefile with the contents:

LIST=OS CPU VARIANT
ifndef QRECURSE
QRECURSE=recurse.mk
ifdef QCONFIG
QRDIR=$(dir $(QCONFIG))
endif
endif
include $(QRDIR)$(QRECURSE)

Then, you can specify build directories for whichever target variants you need, and the toolchain automatically supplies the right compile flags. These directories follow the format $OS-$CPU[-$VARIANT ...].

QNX SDP 8.0 supports the following operating systems:

  • nto (neutrino)
  • linux
  • win64

When building for Neutrino (SDP 7.1), the supported CPUs include:

  • aarch64
  • x86_64

Some supported variants include:

  • o (produce an executable program)
  • so (produce a shared object library)
  • dll (produce a versionless shared object library, typically for use with dlopen())
  • a (produce a static library)
  • a.shared (produce a static library containing PIC objects, for linking into so libraries)
  • le (little endian)

For example, nto-x86_64-so builds a shared object library for QNX on x86_64 hardware, and nto-aarch64-o-le builds an executable for QNX on aarch64le hardware.

The variant build folder would contain a Makefile, including all the definitions from common.mk:

include ../common.mk

The project now has the following structure:

project-root:

→ common.mk

→ Makefile

→ nto-aarch64-o-le:

→ → Makefile

→ nto-x86_64-so:

→ → Makefile

Then, running make from project-root builds binaries for x86_64 and aarch64le.

Using QNX Makefiles has many advantages and disadvantages when compared to popular conventional build systems that are worth considering to determine if it will make a good fit for your project.

Advantages include:

  • Designed to easily enable cross compilation for QNX.
  • Safe default compile options.
  • Integration with QNX Momentics IDE.

Disadvantages include:

  • Primarily for cross compiling to run on QNX and may not be suitable for other applications.
  • May increase build time when compared to ordinary Make.

QNX Makefile tools export many macros to use in the build; such as macros that can be read to glean information like installation paths, and macros that can be edited to change build rules. For a list of these macros, visit "Using the standard macros and include files" in the Programmer's Guide. By forwarding values from QNX Makefiles to their counterpart in another build system, many of these macros can be used to facilitate out-of-source cross compilation using a more common approach. For more information, refer to the "Ported open source projects" section of this guide.

Page updated: