How can I provide child image configuration fragments for a specific build (e.g. Extra CMake arguments) ?

[Anthony Ambuehl]

I am using NRF Connect SDK 2.3.0  with corresponding toolchain and VS Code with latest extensions.

I have created applications outside of the NCS hierarchy and would like to avoid modifying files in NCS.

In my project I have multiple build configurations.  Each build configuration has different combination of configuration overlay files. 

I need to also provide various configuration overlay files to the child images especially MCUBOOT.

I have been able to do this with Extra CMake arguments -Dmcuboot_OVERLAY_CONFIG="/absolute_path/that/is/specific/to/my/git/clone" however I want to avoid using absolute paths since they won't work correctly if i git clone into a different location.

Is there anyway I can pass build configuration specific child image configuration files from the project without using an absolute path?

Actually on additional inspection, I also noticed that the generated CmakeCache.txt is full of absolute paths... so its completely unsuitable for sharing with another developer via git.

What is the best approach for constructing a project with multiple builds that I can share with other collaborators?   Should I edit the generated file and replace the absolute paths ?

After I change CMakeCache.txt is there a step to regenerate things?

[Hieu]

Hi Anthony Ambuehl,

For that purpose, you can look into the Build Type feature of the nRF Connect SDK. It is introduced here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/nrf/app_dev/build_and_config_system/index.html#ncs-additions.

The rule about providing build type .conf and .overlay file for child images are explained here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/nrf/app_dev/multi_image/index.html#image-specific-variables.

You can also look into setting the configurations in CMakeList.txt instead. As you have multiple configurations in a project, you likely will still need a conditional handling in the CMake file to switch between the configurations, but that still solves the absolute path issue, and helps each configuration to be specified with one argument instead of multiple.

I am not a CMake expert, but I wonder if there is a way to setup a conditional statement based on the build folder name too. That would be even better.

Here is an example where my colleague set a single MCUboot Kconfig with CMake: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/blob/v2.2.0/bootloader_samples/keys_and_signatures/mcuboot_smp_custom_key/CMakeLists.txt#L5.

This document describes how to configuration files can be set using CMake files: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/zephyr/develop/application/index.html#important-build-system-variables.

Finally, please understand if our responses are delayed for the next ~1.5 weeks due to a holiday here. My apology for the inconvenience.

Hieu

[Anthony Ambuehl]

Please also help me with this additional question..

What is the best approach for constructing a project with multiple builds that I can share with other collaborators?   Should I edit the generated file and replace the absolute paths ?

Which files would I add to git and how do I make it not have absolute paths that would break if not installed in the exact same location?

[Anthony Ambuehl]

Also the build type approach forces me to maintain multiple copies of prj.conf and child_image/mcuboot.conf. 

The mulitple prj_<buildtype>.conf is easier to deal with, I can move all of the common settings into a top level overlay_common.conf  .

Unfortunately, the child_image/mcuboot.conf must be duplicated for every build type, so this really makes maintaining multiple builds difficult.   It really seems there is no way to achieve an overlay behavior  for child image while keeping other files common.

[Hieu]

Anthony Ambuehl said:

What is the best approach for constructing a project with multiple builds that I can share with other collaborators?   Should I edit the generated file and replace the absolute paths ?

There are some recommended method described in this page:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/nrf/developing/adding_code.html.

For your case where the build configuration is important, I think the methods are best combined with the build type feature. This is where I address your next concern:

Anthony Ambuehl said:

Also the build type approach forces me to maintain multiple copies of prj.conf and child_image/mcuboot.conf. 

The mulitple prj_<buildtype>.conf is easier to deal with, I can move all of the common settings into a top level overlay_common.conf  .

Please review this documentation that I have previously linked. Having built type .conf files for child images are possible.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/nrf/app_dev/multi_image/index.html#image-specific-variables

Those methods are not really designed to keep build configuration folders around though. They are designed to work with build types. Please see if you can adopt this approach.

---

If you must keep build configurations in your git project, below I can share how I personally do it for my non-version-control backup.

I use the VS Code Extension in my work, and what I observe is that there are two options to reduce the size of the build folder.

1. The first one is recreating it, and stop at the generating step, not build.
2. The second is to run west build -t clean.

I have seen that the recreating is significantly smaller with significantly fewer file. So, I often try to go with this.

[Anthony Ambuehl]

Based on your feedback, I have taken the approach of putting a build script into the folder which calls west with appropriate parameters to generate the build folder. 

I have also found in certain cases it helps to add child image overlays into the CMakeLists.txt for example

SET(hci_rpmsg_OVERLAY_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/overlay_hci_rpmsg.conf")