compdb: mergedCompileCommands for CMake subprojects

[Felix-El]

This changes visible behavior

The following changes are proposed:

Add an option to collect all compile_commands.json from the build directory and merge them into one for consumption by vscode-cpptools.

The purpose of this change

The option "Merged Compile Commands" will merge all compile_commands.json from the build directory into a new JSON file. This functionality is an enabler for IntelliSense in ExternalProject based "superbuilds".

Other Notes/Information

In order to get IntelliSense support with superbuilds, few settings are required:

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

[ghost]

All CLA requirements met.

[andreeis]

@Felix-El, can you describe how you can have more than one compile_commands.json in the same project? I am not familiar with this scenario and I need a repro to test your PR, before we accept it.

[Felix-El]

@Felix-El, can you describe how you can have more than one compile_commands.json in the same project? I am not familiar with this scenario and I need a repro to test your PR, before we accept it.

Sure, this feature can help a lot if you are, like I am, working with CMake subprojects, i.e. using ExternalProject.
Each subproject typically has its own private build, say build/subproj1, build/subproject2, etc.
Now if I let CMake generate the compile_commands.json I receive one of those files in the build folder of each subproject
(with nested subprojects there can be again multiple).
As such projects evolve it is impractical to carry along a list of project names or compile_commands.json paths, hence I decided to find them by crawling the build directory.

Here is a multi-subproject test I've added with a new CMake featrue (scheduled for 3.22): https://gitlab.kitware.com/cmake/cmake/-/tree/master/Tests/InstallMode
It should serve well to verify this PR.

[andreeis]

@Felix-El, we have a suggestion if you can update your PR. Let's have instead one path setting for the merged compile commands ("cmake.mergedCompileCommands") and no boolean because we can deduce everything based on the path being set or not.
What do you think of this approach?

[Felix-El]

@Felix-El, we have a suggestion if you can update your PR. Let's have instead one path setting for the merged compile commands ("cmake.mergedCompileCommands") and no boolean because we can deduce everything based on the path being set or not. What do you think of this approach?

I assume that means the *.json crawl & collect logic would remain as proposed, just the configuration would add a cmake.mergedCompileCommands (which allows to create a separate merged JSON) instead of a cmake.collectCompileCommands (which would affect cmake.copyCompileCommands JSON).

If that is correct I totally agree!

[bobbrow]

Yes. We wanted to avoid requiring setting both the merge and copy settings to get predictable behavior.

[Felix-El]

Ok, please give it another look...