Support Multiple CMakeLists.txt without Requiring a Multi-Root Workspace

Brief Issue Summary

I maintain a repo in which there are multiple target architectures. For the most part, the executables being built for the different architectures have separate code, build dirs, and CMakeLists.txt files, because the processes running on the different archs do completely separate things (think a multi-component system made up of RTOS devices, beefier “cortex” boards, etc). There are some libs and include dirs shared commonly between these exec dirs, but not many. The ideal solution would be for CMake Tools to build these separate architectures independently. I tried a multi-root workspace + symlinks for the common code, but ran into issues with that (see https://github.com/microsoft/vscode-cmake-tools/issues/1371). Since symlinks are clunky and not great for developers who don’t want to use Unix, ideally there’d be a way to just give CMake Tools a list of CMakeLists.txt files for it to build- something like cmake.cmakelist_files. Maybe such a setting could default to [] so that CMake Tools would carry on using ${cmake.sourceDirectory}/CMakeLists.txt like it normally does, but if cmake.cmakelist_files is set to multiple CMakeLists.txt files, it would build them all separately with different build-* dirs. Obviously it’d also be ideal that intellisense is supported from using the compile_commands.json from all the resulting build-* dirs, and auto-switches context depending on what file you’re looking at.

A few potential ways to do this:

• Run multiple CMake Tools processes? Can VSCode even do that?
• Run CMake Configuration on all the CMakeLists.txt files listed in cmake.cmakelist_files (thus producing multiple build-* dirs), then merge all the compile_commands.json files into a single such file?

This request might sound a little far fetched, but I could see it being quite valuable and crucial to this extension’s long-term success. Having to run CMake multiple times is quite common, not just for repos with multiple components. For example, building third-party libs that don’t support add_subdirectory(path/to/some-third-party-lib). It’d be AMAZING to have full intellisense support on such third-party libs.

Thanks for the awesome extension!

Expected:

N/A

Apparent Behavior:

N/A

CMake Tools Log

N/A

Developer Tools Log

N/A

Platform and Versions

• Operating System: Win10 Remote-SSH’d into Ubuntu 20.04
• CMake Version: 3.16.3
• VSCode Version: 1.47.1
• CMake Tools Extension Version: 1.4.1
• Compiler/Toolchain: Multiple (hence the issue as described lol)

Other Notes/Information

N/A

[ryanwinter]

I was surprised to learn this feature didnt exist today 😭

[elahehrashedi]

This is a proposal on how to change the design of the extension to accept multiple CMake projects in the same workspace folder. Currently, we are supporting the multi-root case, in which there is only one Cmake project in every root.

1. The case where there is only one project per workspacefolder (the current design):

In this scenario the sourceDirectory and buildDirectory are defined as below:

"cmake.sourceDirectory": "${workspaceFolder}",
"cmake.buildDirectory": "${workspaceFolder}/build",

The buildDirectory, if not defined, will default to "${workspaceFolder}/build".

2. The case where there are multiple project folders in the same workpaceFolder (options for the future design):

In this scenario, the sourceDirectory will be defined as below:

    "cmake.sourceDirectory" : [
        "D:/tests/multiroot/root1",
        "D:/tests/multiroot/root1/subroot1",
        "D:/tests/multiroot/root1/subroot2"
    ],

Based on this, there are few approaches to define the buildDirectory:

2.1. defining an array of buildDirectory, …

	"cmake.buildDirectory" : [
	    "D:/tests/multiroot/root1/build",
	    "D:/tests/multiroot/root1/subroot1/build",
	    "D:/tests/multiroot/root1/subroot2/build"
	]

Cons: • In this approach, we will need to define install directory, and etc. as an array too. • User would have to match the paths across arrays, which is error-prone

2.2. Keeping the default as below, but change the way we resolve ${workspaceFolder}:

"cmake.buildDirectory": "${workspaceFolder}/build"

In this approach, we resolve the workspaceFolder using the source directory path. Cons: • This will break the current users that their source directory was not the same as their workspace folder, e.g. the CMakeLists.txt is not located in the root of their workspace folder, or is even located outside of the workspace folder.

2.3. Creating a new variable ${sourceDirectory} and encouraging the user to use this as their buildDirectory:

"cmake.buildDirectory": "${sourceDirectory}/build"

• In this approach, when the user is adding the "cmake.buildDirectory" for the first time in their settings.json, we will default to "${sourceDirectory}/build". This will work in both situations where the user is defining a single or multiple source directories.
• If the user hasn’t defined the buildDirectory and has defined only one source directory, we will default to "${workspaceFolder}/build" as before. This behavior is currently in place and we don’t want to change it.
• If the user has defined multiple source directories, and has not defined a buildDirectory, we will default to "${sourceDirectory}/build".
• If the user has defined multiple source directories, and has defined the buildDirectory as "${workspaceFolder}/build" we will show a warning explaining that this will create an issue for them, as there are multiple projects in the same workspaceFolder, and as a result, all will try to write the build files in the same folder.

We are planning to implement design # 2.3.