Project broken after git clean (Project setup in CMake)

jwichmann · ‎2025-11-17

Hello,

I have a small problem here. When I run a clean in git, the directories .vscode, .settings, and build are deleted. If the project needs to be rebuilt, the Setup STM32Cude project function has to be executed manually, and the board/device has to be specified manually again. This is very error-prone.

Is there a way to start this project setup from CMake or from CMakePresets.json?

For example, if no compiler was found?

In CMake, the correct settings are already known.

Cartu38 OpenDev · ‎2025-11-22

@jwichmann why not adding these .settings & .vscode stuff to your source control resources ?

Myself I'm not hurted to consider any tool has the need for internal metadata ... they are part of the project kind of.

Looking at STM32Cube native proposal creating a so called empty project an .gitignore file is promoted ... it's crystal clear .settings has to be preserved

jwichmann · ‎2025-11-23

Because user-specific configurations are also stored in the .settings and .vscode directories. In my opinion, these have no place in a GIT repository.

For example, .settings/bundles.store.json stores whether st-link or j-link is used as the programmer. This is a matter of user preference, but not really relevant to the project. It should also not be relevant whether GCC or Clang is used as the compiler. This should be controlled by the CMake file itself, as well as compiler switches in the code. The paths of the current toolchain are stored in .vscode/settings.json.

I found out that if I keep the .settings/ide.store.json file, I can achieve the project setup with the desired default settings. Even if CMake configure is executed automatically three times, twice with compiler errors and the third time correctly.

Cartu38 OpenDev · ‎2025-11-23

@jwichmann you are kind of confirming all my points :-).

@jwichmann wrote:
I found out that if I keep the .settings/ide.store.json file, I can achieve the project setup with the desired default settings. Even if CMake configure is executed automatically three times, twice with compiler errors and the third time correctly.

Demonstrates these metadata are must have. Why are they must have ? Because they are supporting your local system install management promoting to VSCode extensions paths to must have binaries which are compilers, debuggers acting under the hood of VSCode. VSCode is only a GUI ... all the rest is out of VSCode.
Stuff is failing at first ages because .settings metadata not taken into account at first. At first regular CMake Tools extension is acting and this extension is not aware of STM32Cube additions. Post CMake Tools contributions STM32Cube is acting and by magic stuff starts to work.

@jwichmann wrote:
Because user-specific configurations are also stored in the .settings and .vscode directories. In my opinion, these have no place in a GIT repository.

Yes and I bet assumed by ST Thanks some other comments. Rational is to ensure reproducibility if you're sharing your project to a friend. Keeping these *bundle* stuff will kind of force your friend to execute your project back enjoying the very same setup. Thanks these metadata your projet is really self contain ... not only application sources but tools moving with.

WDYT ?

jwichmann · ‎2025-11-24

I think ST should design the new development environment in such a way that both approaches/working methods are possible.

I also like the vcpkg way of thinking. For example, I can add a library (without specifying a version), and it will always be installed in the latest version. (This forces the developer to keep the code base up to date.) On the other hand, I can specify the exact version when adding a library or after the fact. Then exactly that version will be installed. (This is helpful for problematic libraries or certified products.)

There are also other reasons, such as porting from one compiler (e.g., GCC) to another (e.g., Clang), where both developers work on the same code base without one constantly overwriting the other's settings in GIT.

There are also the preferences of individual developers when it comes to compilers and debuggers.

Cartu38 OpenDev · ‎2025-11-24

@jwichmann I'm with you.

My 2 cents is STM32Cube currently is trying to achieve this. If you want embrace fully the automation let's keep .settings. If not you can get rid of - not adding to source control but maybe keep only ide.store.json to get device itself - but means more relies on you as end user.
This *bundle* stuff is only a way to manage for you $PATH env variable. see https://community.st.com/t5/stm32cubeide-for-visual-studio/stm32cubeclt-overriding-system-path-variable/td-p/676286
I've feeling STM32Cube has done its own vcpkg mechanism ... pro / cons ?

jwichmann · ‎2025-11-24

To be honest, I only see disadvantages in an ST proprietary solution.

Okay, I didn't understand the point of vcpkg at first either. But since I started developing with KiCad, I've grown to love it.

Not everyone likes vendor lock-in.
It takes a lot of time and resources to develop a comparable tool, and therefore also money.
vcpkg is already supported by VS Code.
vcpkg is very powerful and universal.
vcpkg already has built-in license management.
It is very easy to extend vcpkg with your own ports or, if necessary, ST-specific ports.
You can combine host application and MCU application development, e.g., if the same algorithm is required in both worlds, including the bootloader and the encryption tool.

I think it's better to put the ST bundles in an ST-specific port and rely on vcpkg in the long term. He's not reinventing the wheel. Instead, he's taking a wheel and making it a little bit better.

Thank for the link.