4 ms·
It isn't a native CMake solution, but the ROS (Robot Operating System) community has been dealing with the "build many CMake/python/other projects in parallel"
by mikepurvis 7y ago
It isn't a native CMake solution, but the ROS (Robot Operating System) community has been dealing with the "build many CMake/python/other projects in parallel" problem for a long time, and has produced several tools and which address this.
The most recent effort is called colcon, which you can find here: https://colcon.readthedocs.io/en/released/ https://colcon.readthedocs.io/en/released/
In the past (for example with catkin_tools, colcon's predecessor), the biggest barrier to use with conventional CMake packages has always been that they don't export dependency information in an easily machine-consumable way, so any regular CMake package brought into the workspace needed to have a package.xml file patched into it.
Colcon still has the ability to bring in extra metadata for things like ensuring environment variables and so on are set up correctly in the final workspace, but it's gotten a lot better at parsing/interpreting the native expressions of dependency and figuring out what to do. See for example how you build the multiple projects which make up the Gazebo simulator with colcon:
https://colcon.readthedocs.io/en/released/user/quick-start.html#build-gazebo-and-the-ignition-packages https://colcon.readthedocs.io/en/released/user/quick-start.h...
Of course, colcon also supports adding python/setuptools repos, and includes experimental support for bazel, gradle, cargo, and other buildsystems which can do an "install" step into a reasonably sane FHS tree. So in that way it's kind of like a cross-language supercharged virtualenv— it gives you the benefits of building multiple pieces of a system from source, semi-isolated, without the hassle of dealing with containers or VMs, where you also have to have all your tools in the isolated environment.