STM32Cube CMake Support incorrectly configures several CMake Tools settings

[ankes]

Hi all,

Dwelving deeper into the life and soul of the STM32Cube extensions I have come across a rather evil little bug. Luckily it is quite easy to reproduce.

1. Use CubeMX to generate a boilerplate CMake project for any STM32 chip
2. Open VS Code, and open the folder
3. In VS Code, disable STM32Cube CMake Support extension
4. In VS Code, hit "F1" and type "edit user". Select "Preferences: Open User Settings (JSON)"
5. In the JSON editor, remove the "cmake.environment" key
6. In VS Code, re-enable the STM32Cube CMake Support

Expected outcome:

The "cmake.environment" setting should be put into the ".vscode\settings.json" file, similar to how "cmake.cmakePath" is placed there by the extension.

Observed outcome:

The "cmake.environment" setting stays in the user's local settings file and affects all projects, ST and non-ST alike. The "${env:PATH}" evaluation is at the end of the line but nevertheless the setting gives preference to ST-sourced tools and executables if they happen to be found from from the folders that get added to the list.

[Julien D]

 

Hi @ankes,

Thanks for noticing. Basically, this is somewhat intentional. The STM32Cube CMake Support extension sets this setting for you at least once each startup.

Without it, there is no chance to have cube and cube-cmake in the environment loaded when CMake processes are spawned.

The reason we placed it in the global cmake.environment is that it refers to local absolute paths. If we scoped it to the project, it would break important software development use cases.

Imagine placing your project in any SCM like Git. Having it in .vscode/settings.json works for you but not for others, and even not for you on other computers if working across platforms (Windows, Linux, and Mac). This file could be put into .gitignore and regenerated each time, of course. But how do we handle cases where people want to place other settings inside it that must be in source control? Conflicting use cases here.

That's why it has been put globally.

Yes, we could have put ${env:PATH} in front of our contribution. But since the two paths contain only our tools, it should not impact other tools. Feel free to correct me if I omit any broken use cases. If order really matters to you, you can edit and reorder it. We should not roll it back later since we only check that our paths are defined.