STM32CubeIde for VSCode - workspace dirty by ST files all the time

[andyi]

Hello, 

Long time lurker here. 

First of all, thank you for the extensions, really appreciated the possibility to work directly in vscode.

I have a couple of situation, however, that are really annoying and that I would like to solve.

While developing in vscode with the extension enabled. It is sufficient to update the CMake presets in order to have the tools installed by the ST extension to make the git repository dirty.

If before committing the files to the repo a pre-commit that formats the files in a proper way then it is amplificated.

The files:

•  c_cpp_properties.json in the .vscode folder is always updated with the compileCommands updated if dynamic folders for Debug and Release are used
•  .clangd configuration file is updated in the CompilationDatabase field.

In my opinion there are two different types of settings:

•  settings that needs to be persinstent, and maybe reusable on different computers by different users
• settings related only to the current run

There should exist a good way for switching branches and change configuration without having to worry about the extension that changes files at his willing.

Is it unclear if I can put under gitignore the content of .settings folder. Anyway I cannot place under gitignore the other two files mentioned above because I am using them for other configurations.

Thank you in advance

[Cartu38 OpenDev · Accepted solution]

@andyi 
No clue myself about .vscode & .clangd updates and way to kept them static.

About .settings according to me yes it has to be part of your source controlled assets. Content is part of your project, the first being bundles* files which are the one keeping memory of tools you're using. These files are th way for you to get reproducible results overtime.

[andyi]

Thank you for your reply.

Yes, I can understand about the .settings folder. This is a common topic also with other tools / solutions.

I do not understand, the .vscode and the .clangd updates. Those are the more annoying.

My understanding is that the tools are copied and rebranded probably with some customization. It looks to me a bug that those files are updated in this way. No idea about how to notify them as bugs if not writing here...

[vincent_grenet]

@andyi 
Thanks for reporting. I confirm that the ST community is the right place to reach the R&D team.
I also confirm @Cartu38 OpenDev's OpenDev contribution regarding .settings. As you noticed, this is quite a common practice. No automation is possible without a couple of proprietary metadata files.
Regarding c_cpp_properties.json and .clangd, internal tickets have been submitted. We will keep you updated here.

[andyi]

Thank you for the update.

Would love to see it fixed. 

Have a nice day.

Andrea

[LukasLang]

Regarding the compile_commands.json file, I have CMake set to copy them to build/, i.e.

"cmake.copyCompileCommands": "${workspaceFolder}/build/compile_commands.json",

This way, the path to the file is stable, regardless of build configuration (it simply reflects the last build). Now the extension just needs to not break my c_cpp_properties.json file all the time, and everything would be great. I assume there is currently no way to simply disable the "feature"?

[andyi]

Currently I disabled st extensions. I reverted back to the original extensions.

I have the following in my cmakelists.txt file:

  execute_process( 
    COMMAND
      ${CMAKE_COMMAND} -E create_symlink
      ${CMAKE_BINARY_DIR}/compile_commands.json
      ${CMAKE_SOURCE_DIR}/compile_commands.json)

This has the benefit of working out of the box with CMakePresets that defines different build dir and is not tied to vscode doing something. It works the same running in the terminal, in vim, emacs and all other editors

[Suess]

@vincent_grenet, should I add the ".clangd" file to our .gitignore as it is always auto-generated or is it a user configuration file?

[Suess]

As we continuously battle this line ending nonsense as we're all using Windows OS. We'll be rolling out a `.gitattributes` in our projects against better judgement.

[vincent_grenet]

@Suess 
In our view, the .cland file must be included in source-controlled files.
We are working to resolve unnecessary updates, which are corner cases. However, we have reproduced some of these cases and are taking action.