Integrate with colcon build tool (multi-root workspace)

[Ryanf55]

Background

I'm a robotics developer who uses colcon to build and test multiple C++ packages.

An example repository is navigation2, which contains a number of folders with CMakeLists in each project. There is no top-level CMakeLists. The repository contains a VSCode devcontainer at the top level. Developers will usually be making code changes in multiple projects in a single development task.

In CLI, to build the whole project, you type colcon build, which recursively builds each project in the correct order (specified by the package.xml).

As a ROS developer who uses CMake a lot, I really struggle to use the CMake Tools when working in a colcon project because of the multi-root workspace.

Desired behavior

I can run a build task that "builds everything" under the CMake tools. If there is an error at configure time, the CMake tools will automatically add a breakpoint and open the CMake tools debugger

Actual behavior

I have to build all the dependent packages, then configure with VSCode to select the failing package as the root, source the workspace, and rebuild with the debugger. If I am doing a build system rework, such as changing the name of a target used in many other projects in the workspace, this workflow is very tedius and time consuming.

Request

Are there any recommendations for working in a multi-root workspace where there is not a single top level workspace.
I understand colcon is a tool not all CMake developers use, however I can imagine there are others with similar repository layouts that use build scripts to build multiple packages and want a similar debug experience for CMake configuration.

[gcampbell-msft]

@Ryanf55 This is a very interesting use case, thanks for the post and apologies for the time it took to finally answer to this.

We are in the midst of trying to improve some multi-root scenarios in the extension #4112. However, this feels to me like a much more niche case.

However, it's a very interesting feature request. I deduct one main feature request out of this:

• When a configure fails, have CMake Tools automatically put breakpoints at that location and open the CMake Debugger.

I imagine that the feature requests you mention and your scenario, due to the complexity as well as the limited number of users that may experience it, will not be a high priority for us for some time. However, I would be interested to have you parse out the specific feature requests that you think would help your scenario, and open them as issues so that we can garner community interest and possibly prioritize them 1 by 1 over time.

Our work in the multi-root area hopes to make the generic multi-root experience easier, but I can't make any gaurantees that it will accomplish the goals you'd like it to.

Thanks for the in-depth discussion post, and I look forward to seeing any feature requests (in the form of an issue) you post.

Thanks for your patience and understanding, both in how long this post went unanswered, as well as patience in us implementing any feature request that you may post.

Thanks!