Build system support overview

After creating an application, you must set up a build configuration to build an application. A build configuration compiles and links the application components. It is composed of different configuration options.

You can create build configurations in Zephyr and the nRF Connect SDK using CMake and System build (sysbuild). These build systems are integrated with the Devicetree and Kconfig configuration systems and are fully supported in the extension.

The main difference between the two systems is the way they handle child images. While the default CMake build system nests child images in a gradually more layered hierarchy, sysbuild lists the child images in a flatter hierarchical structure, making it easier to work with applications that use several images.

Snippet support

The extension also provides support for snippets when working with either CMake or sysbuild. This is a Zephyr mechanism for defining portable build system overrides that could be applied to any application. Read Zephyr's Snippets documentation for more information.

You can set snippets for use with your application by adding them on the Add Build Configuration page.

CMake build system

CMake is the default build system for Zephyr and nRF Connect SDK and it has two stages: configuration and build.

The configuration stage takes place when you create a build configuration. CMake executes build scripts from CMakeLists.txt to create a model of the build for the specified build target and generate the final build scripts at the application source directory. At this stage, CMake gathers configuration from different sources to produce a set of output files that will drive the build process. The different sources can include source files such as main.c and configuration input files such as devicetree and Kconfig files. You can check all files included in a build configuration in the Details View.

Example of a CMake build file structure for a multi-core device

<home>/application              # CMake standard build configuration
└── build
    ├── application             # Application MCU
    |   └── build               # Application MCU child image
    |       └── <child>         # Application MCU child image
    ├── mcuboot                 # Application MCU
    ├── multiprotocol_rpmsg     # Network MCU
    └── b0n                     # Network MCU

When the build configuration is ready, you can use the Build action to start the build stage, which executes the final build scripts. (You can also have this action trigger automatically if you tick the Build after generating configuration checkbox when you create the build configuration.)

For more information about how this build system works, see Zephyr's CMake build system and Building an Application documentation pages.

System build (sysbuild)

System build (sysbuild) is a high level build system that you can use to combine multiple build systems into a hierarchical structure. With sysbuild working as a higher-level umbrella, you can build images for one or more boards or domains as part of a single process.

Sysbuild is written in CMake, comes with its own Kconfig options, and is integrated with west. The sysbuild build configuration is generated using the sysbuild's CMakeLists.txt file (which provides information about each underlying build system and CMake variables) and the sysbuild's Kconfig options (which are gathered in the sysbuild.conf file).

When you use sysbuild, the build configurations that target different cores or domains appear under one build directory under the selected application, grouped according to the separate cores or domains. See the following example:

Example of a sysbuild build file structure for a multi-core device

<home>/application/build             # Sysbuild build configuration
 ├── application                     # Application MCU
 ├── <child>                         # Application MCU child image
 ├── bootloader                      # Application MCU
 └── multiprotocol_rpmsg             # Network MCU

Both building and flashing of a sysbuild build configuration happens in a sequence. For more information about how sysbuild works, see its Zephyr documentation page.

To distinguish CMake variables and Kconfig options specific to the underlying build systems, sysbuild uses namespacing. For example, sysbuild-specific Kconfig options are preceded by SB_ before CONFIG and application-specific CMake options are preceded by the application name. For more information, see Configuration namespacing on the Zephyr documentation page.

Because sysbuild is written in CMake and is integrated with the CMake build system, it follows the same stages: configuration and build. In the extension, you can enable sysbuild when you create a build configuration.

Important

Sysbuild is only available from the nRF Connect SDK v2.4.0.

When you use sysbuild in the extension, the build configuration is generated by passing --sysbuild to west build, making the top build folder a sysbuild folder, with the application as a child image. Any sysbuild-specific CMake or configuration files are picked up by default. When you select the top sysbuild folder in the Applications View, the extension will switch its actions in the background to sysbuild-related ones. For example, you will still see the Flash action in the Actions View, but using it will trigger flashing of all sysbuild images.

The following differences in the UI apply to a sysbuild configuration:

• Details View:

  • The View displays the sysbuild file structure, with the source files section including the source files of all child images, as sysbuild-based build configurations do not have any source files of their own.
  • Input and output files are sysbuild-specific.

• Devicetree Visual Editor: There are no devicetree files for sysbuild, so all devicetree actions and views are hidden.

• Actions View: There is no common Memory Report for sysbuild-based build configurations, so this action is hidden.

For more information, see also How to work with build configurations.