Skip to content

Support multiple compile commands files per project #7029

Description

Type: LanguageService

This is a feature request.

Describe the bug

  • OS and Version: Ubuntu 20.04
  • VS Code Version: 1.53.2
  • C/C++ Extension Version: v1.2.1
  • Other extensions you installed (and if the issue persists after disabling them): ROS (ms-iot.vscode-ros), disabling makes no difference.
  • Does this issue involve using SSH remote to run the extension on a remote machine?: no
  • A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).

Some ROS build systems (catkin_tools, catkin_make_isolated) run CMake separately in different repositories. Thus, passing CMAKE_EXPORT_COMPILE_COMMANDS=ON generates n files for n projects. Merging the files manually is cumbersome, so the ideal solution would be the possibility to specify multiple compile commands files and/or support wildcards in the config.

Expected behavior

This configuration to be valid and all compilation databases merged:

{
    "configurations": [
        {
            "compileCommands": [
              "${workspaceFolder}/build/foo_pkg/compile_commands.json",
              "${workspaceFolder}/build/bare_pkg/compile_commands.json",
              "${workspaceFolder}/build/**/compile_commands.json",
            ]
        }
    ],
}

Activity

  1. Colengms commented on Feb 23, 2021

    @Colengms
    Contributor

    Hi Hermann von Kleist (@stertingen) . Thanks for taking the time to suggest this.

    Since the project is using CMake, have you considered using the CMake Tools extension? CMake Tools provides configurations to the C/C++ Extension, and should properly handle the full hierarchy of projects from a single top-level CMakeFiles.txt.

  2. stertingen commented on Feb 23, 2021

    @stertingen
    Author

    Hi Hermann von Kleist (@stertingen) . Thanks for taking the time to suggest this.

    Since the project is using CMake, have you considered using the CMake Tools extension? CMake Tools provides configurations to the C/C++ Extension, and should properly handle the full hierarchy of projects from a single top-level CMakeFiles.txt.

    There exists a single top-level CMakeLists.txt for catkin_make, but not for the tools I mentioned (catkin_tools & catkin_make_isolated). The point of catkin_make_isolated is avoiding side-effects during the build of packages due to global CMake variables. A single top-level CMakeLists.txt would break that isolation.

  3. Colengms commented on Feb 23, 2021

    @Colengms
    Contributor

    Hermann von Kleist (@stertingen) With CMake Tools, it's possible to specify an arbitrary CMakeLists.txt location, using cmake.sourceDirectory. Since it sounds like you're not using CMake Tools to build, you could use CMake Tools just to provide configurations to the C/C++ Extension, by pointing it to a CMakeList.txt that includes all of the other project directories.

  4. stertingen commented on Feb 26, 2021

    @stertingen
    Author

    Hermann von Kleist (@stertingen) With CMake Tools, it's possible to specify an arbitrary CMakeLists.txt location, using cmake.sourceDirectory. Since it sounds like you're not using CMake Tools to build, you could use CMake Tools just to provide configurations to the C/C++ Extension, by pointing it to a CMakeList.txt that includes all of the other project directories.

    You mean, using add_subdirectory()? This solution sounds rather hacky to me, I think, I stick to this one: catkin/catkin_tools#551 (comment)

  5. kjeremy commented on Mar 3, 2021

    @kjeremy

    Colen Garoutte-Carson (@Colengms) I don't think that would work for ROS since the top-level CMakeLists.txt is autogenerated. What I really want is glob support:

    "compileCommands": "${workspaceFolder}/build/**/compile_commands.json"
  6. github-actions commented on May 3, 2021

    @github-actions

    This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog.

  7. added
    more votes neededIssues that have been postponed until more community members upvote it
    on May 3, 2021
  8. modified the milestones: Triage, Backlog on Jun 21, 2021
  9. removed
    more votes neededIssues that have been postponed until more community members upvote it
    on Jun 21, 2021
  10. github-actions commented on Jun 21, 2021

    @github-actions

    This feature request has received enough votes to be added to our backlog.

  11. Plaba commented on Jun 24, 2022

    @Plaba

    For those of you needing this feature now, an easy hack is to merge all the compile_commands.json into one file. This command worked for me on a ROS project.

    cat build/**/compile_commands.json | jq -s 'add' > build/compile_commands.json

    After that, set compileCommands to "${workspaceFolder}/build/compile_commands.json" and your multi-cmake project should work

  12. visstro commented on Dec 20, 2022

    @visstro

    As an alternative, there is also clangd plugin which supports multiple configs files per directory, but also regex on paths.

    Example .clangd config file:

    Diagnostics:
        UnusedIncludes: Strict
    
    ---
    
    If:
        PathExclude: .*/tests/.*
    CompileFlags:
        CompilationDatabase: build/production/
    
    ---
    
    If:
        PathMatch: .*/tests/.*
    CompileFlags:
        CompilationDatabase: build/testing/
    
  13. MichaelVoelkel commented on Nov 15, 2023

    @MichaelVoelkel

    I would also love this feature. Well, actually I have a multiple-project-workspace and would like to have one per project. Each project generates its own compile_commands.json (naturally), so each should optimally have its own file. But I would also be fine to just have one for all.

  14. sla89 commented on Oct 1, 2024

    @sla89

    This may also needs adaption of C_Cpp.default.compileCommands which is currently just a string but should be an array to also support multiple file in a workspace.

    The workaround of Szymon Strojniak (@visstro) currently works! Thanks.

  15. added
    fixedCheck the Milestone for the release in which the fix is or will be available.
    on Dec 30, 2024
  16. sean-mcmanus commented on Jan 10, 2025

    @sean-mcmanus
    Contributor
  17. locked and limited conversation to collaborators on Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    • Status
      Done

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions