NRF Connect for VS Code doesn't save configuration changes

[Jeffrey Haynes]

I have been attempting to add a -Dmcuboot_OVERLAY_CONFIG item to the "Extra CMake arguments" section of the Build Configuration page.  When I do, the build successfully completes and the Build Configuration page closes.  Next time I open the build page, the CMake argument is missing.  I also can't figure out where the extension is meant to be saving this stuff.  Would be nice if there was a .json file or something to look at to see what's going on.

I should probably also note that upon creating a new project there are no CMake arguments.  After my item gets deleted, any arguments I've added get removed and instead a BOARD_ROOT item is added.

[Jeffrey Haynes]

I think I see now.  Basically it's just setting up build directories and configuring everything. 

So going back to a configuration and editing it is meaningless?  Why is it an option then?

[Priyanka]

Hi Jefferey,

Sorry for the delayed response. 

Next time I open the build page, the CMake argument is missing. 

Do you mean when you open this build page

This is just an interactive page to build the project and once you have built it, all your requirements will be added to the project and opening this page again will not show the arguments you have set for the previous "build".

Also, when you add the "Extra CMake arguments", you are making a change to the input file and it is recommended to "Pristine Build" in such cases.

-Priyanka

[Jeffrey Haynes]

I think I'm following but then why have an option to "edit" the build configuration if those values don't persist?  What is being edited?

[Priyanka]

The changes that you make gets saved in the CMakeCache.txt in the build folder. It can also be saved as Preset as well. Then the build configuration will be saved in the CMakePresets file in the project folder. 

Also, I am not sure I follow what you are saying about an "edit" option. Could you maybe attach a screenshot of where you see this?

-Priyanka

[Peter Maxwell Warasila]

I assume the OP is referring to this dropdown context menu:

This context menu, and the way that it's listed here, implies that the build configuration used to generate the configuration is persisted and could be used to regenerate the build system. In my opinion, it should be.

I'm running into an issue at the moment where we need to pass a Kconfig fragment to mcuboot, which is typically performed using an extra CMake argument, "-Dmcuboot_OVERLAY_CONFIG:STRING=path/to/fragment". However, this is lost if this step is performed again and if a pristine build is ever run from the Actions menu these settings are also lost. Additionally, it does not seem to be saved as part of the preset using "Save Configuration As Preset". What's strange in my case is that the board root cmake argument is being automatically populated and I'm not entirely sure why. It further gives the impression that these configurations persist somewhere.

Update: I was able to use the CMakePresets.txt file to fill the extra CMake argument as intended. However, this is still not taken into account either when editing the build configuration nor when performing a pristine build in the actions menu. This issue effectively makes these workflows pointless because they do not result in the correct build. The only one we will be able to use on this project to do a pristine west build is to create a new build configuration, fill it from a preset, and set the name to the existing the existing build folder. That's a hell of a workaround. I've typically just set up a VSCode task for non-nCS Zephyr projects in the past; at least that always preserves the additional CMake arguments even if it doesn't leverage the features of nRF Connect for VSCode.

[Priyanka]

Hi Peter,

Peter Maxwell Warasila said:

However, this is still not taken into account either when editing the build configuration nor when performing a pristine build in the actions menu. T

Do you mean that when you edit something else or even when you d a pristine build, the extra CMake args are not being taken into account?

I have inquired internally and will get back to you soon.

-Priyanka

[Priyanka]

Hi Peter,

This could happen because you forget to click on the OK button when adding the extra argument. Without that OK it is not completed.

Please confirm by the build logs or by the hovering over the build that the argument is in fact used by CMake. For this to update the user must wait until the build is completed.

-Priyanka

[Peter Maxwell Warasila]

I have ensure that I clicked on the OK button. Just in case it makes a difference, I am using this format when adding the additional CMake argument: 
-Dmcuboot_OVERLAY_CONFIG:STRING="path/to/file"

As you can see, it is not being picked up the build hover tool tip. It is, however, appearing in my CMakeCache.txt file, along with another KConfig overlay which enables the partition manager:

//Extra config fragments for mcuboot child image
mcuboot_OVERLAY_CONFIG:STRING=path/to/file;C:/Users/Peter/ncs/v2.1.2/nrf/subsys/partition_manager/partition_manager_enabled.conf

Perhaps this has something to do with this particular case with the mcuboot overlay?

[Priyanka]

It does look strange as I was able to get the args added. I tried 

-Dmcuboot_OVERLAY_CONFIG:STRING="path/to/file" on the hello_world sample and it works. Which sample are you trying? Could you see if this works on other samples too?

-Priyanka