How to ensure that VSCode gets the correct compile_commands.json for each subproject of the superbuild?

[traversaro]

Perhaps it could make sense that if CMAKE_EXPORT_COMPILE_COMMANDS is set to ON in the robotology-superbuild, we also set it to on in all the subprojects?

@LoreMoretti

[traversaro]

I saw that in https://cmake.org/cmake/help/v3.27/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html that:

This is initialized by the CMAKE_EXPORT_COMPILE_COMMANDS environment variable, and initializes the EXPORT_COMPILE_COMMANDS target property for all targets.

Can't we just tell people to set export CMAKE_EXPORT_COMPILE_COMMANDS=1 in their .bashrc or in their conda environment? I know that we told people not to put stuff in their .bashrc, but this seems quite a generic think that it could make sense to have in their .bashrc. In this way, we do not need to modify our code.

[traversaro]

A second point is how to ensure that the multiple compile_commands.json of the subproject of the superbuild can be found by VSCode. I guess colcon and catkin workspaces have exactly the same problems, and indeed I found some related code for catkin: https://gist.github.com/AlexisTM/a6bb5ee488611e15114aa190b6f79404 . Apparently colcon does this automatically, see https://colcon.readthedocs.io/en/released/user/how-to.html#cmake-packages-generating-compile-commands-json . The related code is in https://github.com/colcon/colcon-cmake/blob/1509c77ecb417dd0b47e4d54b73833fa5e4c1baa/colcon_cmake/event_handler/compile_commands.py#L87-L104 .

[traversaro]

I renamed the issue to track the actual problem we want to face.

[traversaro]

Other related issues in cmake tools for vs:

• Support for multiple compile_commands.json from external projects microsoft/vscode-cmake-tools#915
• compdb: mergedCompileCommands for CMake subprojects microsoft/vscode-cmake-tools#2029
• Multi-project configuration microsoft/vscode-cmake-tools#1120

The last issue refer to Zephyr, that indeed uses west ( https://docs.zephyrproject.org/latest/develop/west/index.html ), that indeed is something similar to cmake-based superbuild/colcon/catkin.

[giotherobot]

I saw that in https://cmake.org/cmake/help/v3.27/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html that:

This is initialized by the CMAKE_EXPORT_COMPILE_COMMANDS environment variable, and initializes the EXPORT_COMPILE_COMMANDS target property for all targets.

Can't we just tell people to set export CMAKE_EXPORT_COMPILE_COMMANDS=1 in their .bashrc or in their conda environment? I know that we told people not to put stuff in their .bashrc, but this seems quite a generic think that it could make sense to have in their .bashrc. In this way, we do not need to modify our code.

This does not seem to work for me: this is how i tested (vscode).

1. enable robsub conda env
2. export CMAKE_EXPORT_COMPILE_COMMANDS=1
3. open vscode from that terminal and build the superbuild
4. check if the files are generated and if the cache is correct, it is not

[traversaro]

I am not sure, but I guess the environment variable is ready only once when the project is configuring for the first time. Indeed, by checking the CMake's source code this is the case: https://github.com/Kitware/CMake/blob/v3.28.3/Modules/CMakeGenericSystem.cmake#L74-L79 .

Indeed this may be quite confusing, and explicitly passing the option may be more clear.

[giotherobot]

Tested the patch and it works, all the compile_commands.json are generated.

Then adding the following to .vscode/settings.json:

{
    "C_Cpp.default.compileCommands": "${workspaceFolder}/build/merged_compile_commands.json",
    "cmake.mergedCompileCommands": "${workspaceFolder}/build/merged_compile_commands.json"
}

allows for intellisense to work.

[traversaro]

Great, can we document this somewhere? @LoreMoretti do you have any suggestion on where to document this?

[LoreMoretti]

Great, can we document this somewhere? @LoreMoretti do you have any suggestion on where to document this?

What about here: ami-iit/ami-commons#4

[giotherobot]

Also in https://github.com/ami-iit/ami-commons/blob/master/doc/visual-studio-code.md maybe? Even though this is more specific to the superbuild

[traversaro]

Great, can we document this somewhere? @LoreMoretti do you have any suggestion on where to document this?

What about here: ami-iit/ami-commons#4

I am a bit afraid that that issue is not in the path of things that new users will encounter when the join the AMI lab. Furthermore, this is a more robotology-superbuild problem, that is related also to users of other labs.

My suggestions are:

• Document how to use VSCode + robotology-superbuild in robotology-superbuild in the robotology-superbuild itself, for example in https://github.com/robotology/robotology-superbuild/blob/master/doc/faqs.md (this is the part more related to this issue specifically)
• Then we should have information in https://github.com/ami-iit/ami-commons/blob/master/doc/visual-studio-code.md on how to setup a C++ project, incorporating it from Document how to setup VisualStudioCode for a repository  ami-iit/ami-commons#4 . Then, in that page we can add a link to how to setup robotology-superbuild + VSCode, added in the previous point. We should link the page https://github.com/ami-iit/ami-commons/blob/master/doc/visual-studio-code.md in the ami new member checklist (or any other place to make sure that all new users interested in that can found it).

[giotherobot]

How about shipping the settings.json file along with the superbuild repo, this would simplify the user operations needed.

[traversaro]

How about shipping the settings.json file along with the superbuild repo, this would simplify the user operations needed.

Sure. Do you think it could make sense to also enable the CMAKE_EXPORT_COMPILE_COMMANDS option by default? If expert users have problems with this, they can always set it to OFF.

[giotherobot]

At this point I would say yes, so the user has to to no action to enable this features in vscode.

[LoreMoretti]

For using clangd extension the merged_compile_commands.json of this comment should be named compile_commands.json.

I have opened an issue on clangd for it: clangd/clangd#1932

But for now, to be compatible with both intellisense and clangd we can just stick to the name compile_commands.json and add the following option for clangd:

"clangd.arguments": [
        "--compile-commands-dir=${workspaceFolder}/build/"
    ],