3 ms·

I'm a longtime CMake user, but I think even within the CMake world, the solution is quite a bit more complicated than just "everything needs to be CMake", with

I'm a longtime CMake user, but I think even within the CMake world, the solution is quite a bit more complicated than just "everything needs to be CMake", with a lot of hassles that arise when multiple generations of the tooling is involved, when you're trying to pass down transitive dependencies, when package X has a bunch of custom find modules with magic to try to locate system versions of dependencies but silently fall back to vendored ones. The higher up the stack you get, the worse and worse these problems get, with high-level packages like Tensorflow being completely intractable: https://github.com/tensorflow/tensorflow/tree/master/tensorflow/lite/tools/cmake/modules https://github.com/tensorflow/tensorflow/tree/master/tensorf...

vlovich123 6y ago
Yup. 100% agree. I totally overlooked the shitshow you'll have managing the different versions of CMake a build might require. Somehow Bazel manages to escape that mess. I think that might be a better foundation, but getting everyone to port to that... it's a tall ask & there's many vocal people who are against improving the build system they work with (hell, I've met many engineers who grumble and strongly prefer Makefiles).
- mikepurvis 6y ago
  I'm obviously pretty biased having come from 10 years of doing infrastructure in the ROS world, but having spent a lot of time integrating this or that random library into a singular product-versioned build, I do quite like the approach of colcon: https://github.com/colcon https://github.com/colcon Basically it has plugins to discover/build various package types (autotools, cmake, bazel, setuptools, cargo), and the "interface" between packages is just the output of whatever the standard install target is for a given package. This makes it totally transparent whether your dependency is built-from-source in your workspace, coming from /usr/local via a sudo-make-install workflow, or coming from /usr via a system package. Under this model, you never pull a dependency as a "subproject" with invocations like include or add_subdirectory; it's always using a standard find_package invocation, where basically the only requirement on participating packages is that they cooperate with long-existing standards like CMAKE_PREFIX_PATH and CMAKE_INSTALL_PREFIX. Vendoring a library is then not making a copy of it in your project tree, but rather as sibling project within the shared workspace that colcon builds.

vlovich123 6y ago

Yup. 100% agree. I totally overlooked the shitshow you'll have managing the different versions of CMake a build might require. Somehow Bazel manages to escape that mess. I think that might be a better foundation, but getting everyone to port to that... it's a tall ask & there's many vocal people who are against improving the build system they work with (hell, I've met many engineers who grumble and strongly prefer Makefiles).

mikepurvis 6y ago
I'm obviously pretty biased having come from 10 years of doing infrastructure in the ROS world, but having spent a lot of time integrating this or that random library into a singular product-versioned build, I do quite like the approach of colcon: https://github.com/colcon https://github.com/colcon Basically it has plugins to discover/build various package types (autotools, cmake, bazel, setuptools, cargo), and the "interface" between packages is just the output of whatever the standard install target is for a given package. This makes it totally transparent whether your dependency is built-from-source in your workspace, coming from /usr/local via a sudo-make-install workflow, or coming from /usr via a system package. Under this model, you never pull a dependency as a "subproject" with invocations like include or add_subdirectory; it's always using a standard find_package invocation, where basically the only requirement on participating packages is that they cooperate with long-existing standards like CMAKE_PREFIX_PATH and CMAKE_INSTALL_PREFIX. Vendoring a library is then not making a copy of it in your project tree, but rather as sibling project within the shared workspace that colcon builds.