VS-Code extension overwrites cmakepresets.

[jslota13245]

Dear Everyone,

We have a custom project which we managed to integrate with the extension. We have a cmakepresets.json file which let's us use all nxp panes and we can import the project with success - however sometimes we observe that the after the import is done the extension overwrites cmakepresets to have only default debug and release configurations. Is there any way to stop the extension from doing that?

[arunkumar_g]

Hello,

We are using vs code plugin version 26.4.45 and it still modifies the preset files. The tool version in mcuexpresso-tools.json is 25.3.

Are there any suggestions ? @Harry_Zhang 

Thanks

[DragosMiloiu]

Hi @arunkumar_g,

 To summarize, right now, the extension relies on the API provided by CMakeTools extension for building projects. Also, extension modifies the CMake presets files to supply required values for variables such as ARMGCC_DIR, SdkRootDirPath, and Python virtual environment settings, which are essential for the build process. In doing so, it introduces absolute paths tied to the local development environment. This makes the presets environment-specific, reducing their portability and making them unsuitable for sharing through version control systems like Git.

 In the June release, we plan to introduce support for the “west” build. Since this process will be entirely managed by the extension, we’ll be able to pass all the necessary parameters to the west command and set the required environment variables. As a result, the extension will no longer need to modify the presets. Of course, this will only help if you are using a project based on a repository that has “west” support (like MCUXpresso SDK, Zephyr, Matter, etc.). Current build system will continue to be available and supported. The user will be able to switch between the two from the project settings.

 If you are using a pure CMake project for which west is not a solution,  we need to send the environment variables another way.

 We investigated multiple solutions for this:

• Using settings like "cmake.environment", "cmake.configureEnvironment", and "cmake.buildEnvironment" would be a very good option, since the values provided here would not need to be absolute paths. Unfortunately, these options do not work with presets. Another issue with this approach is that if users want to build the project from the command line, they will have to set the environment variables manually before launching the build.

• In tasks.json, it is also possible to set environment variables for the CMake task, but again it seems that these are not passed to the build process.

• Use CMakeUserPresets.json. Its purpose is to store local, machine-specific build, configure, and test settings. This will work for non-sysbuild projects, will contain absolute paths (which in this case should be acceptable), and will need to be placed in your project. It should also be added to .gitignore.

For sysbuild projects, the source directory is inside the repository rather than in the project itself. The CMakeUserPresets.json file should be placed in the source directory, i.e., in the repository. The one in the repo will likely need to include one from the project, thus allowing different settings for each project.

Please note that in this scenario the extension will have to meddle with the CMakeUserPresets.json to add/define those variables.

This last one is the one we are planning to implement.

Regards,

Dragos.

[arunkumar_g]

Ok when is the cmake user prese support planned to release? What would be an option until that?

[arunkumar_g]

@DragosMiloiu Any updates on this?

[cristiantepus]

Hi @arunkumar_g ,

We are working on it. Unfortunately, this requires some redesign on our side and it will take some additional time. We'll plan it for our next major release in September.

Regards,

Cristian 

[Harry_Zhang]

Hi @jslota13245 

The MCUXpresso extension tries to ensure compatibility with the SDK and debugger configuration by regenerating default CMakePresets.json with only debug and release configurations.

There is no setting in settings.json or workspace configuration to disable CMakePresets.json overwrite behavior in the extension.

BR

Harry

[jslota13245]

Dear @Harry_Zhang ,

Thank you very much for the reply - could you possibly confirm if my understanding is correct, if there is a debug and release configuration inside the cmakepresets would the extension NOT overwrite cmakepresets - or does it happen every time no matter what?

[Harry_Zhang]

Hi @jslota13245 

I have confirmed with our internal team, this issue was fixed back in  25.05 release.

May I ask what version you are using?

BR

Harry

[jslota13245]

Dear @Harry_Zhang,

In my previous post i wrote:
```
The way extension behaves is not really an issue for us - we would just like to know specific set of rules for the cmakepresets.json reconfiguration to happen so we can adjust our workflow (for example base git repository) so it works for everyone in our team.
```

Is there any update for the guidelines on how to prepare CMakePresets in order for NXP extension not to overwrite it, while at the same time generating correct mcux_include.json? I believe the import of a custom project is the topic. Currently the behaviour is quite random as sometimes we need to import project to workspace, remove it, import again, revert change of CMakePresets, then use extension buttons.

[jslota13245]

Dear @Harry_Zhang ,

We're using version 25.6.97. After some experiments i found out that the situation happen when there is no .vscode folder in the working directory.

The way extension behaves is not really an issue for us - we would just like to now specific set of rules for the cmakepresets.json reconfiguration to happen so we can adjust our workflow (for example base git repository) so it works for everyone in our team.

Best Regards,
Jakub