Conan does a very poor job of managing versions and accidental cycles in your dependency graph. I recall having issues that needed manual patching of conanfiles to bootstrap packages when no prebuilt version existed for the target and it contained itself as a transitive dependency.

Also if you use it, make sure not to rely on Conan center. Their outages can ruin your week.

Why is XMake not mentioned in the list of build systems whereas XRepo is mentioned in the list of package managers? (subjective: XMake is a great tool if you like Lua).

I have made my own tool to solve this problem:

https://github.com/franko/lhelper

It is currently used by nobody except me but it serves me well.

Its strong points are:

- it works on macOS, Linux and Windows - it is possible to choose the options you want to enable for each package - compiles packages using your own compiler toolchain - create static libraries by default but you can choose a shared library.

This is a great overview, very comprehensive.

I personally have a system based on Guix, which is like Nix.

One important note is that doing LTO with such a setup is tricky (and I haven’t attempted it yet).

It is possible to transform existing packages to use your preferred C++ toolchain using —-with-c-toolchain, which avoids the ABI incompatibility trap, but I haven’t figured out how to create LTO-enabled static libs from system packages yet.

vcpkg is well on its way to becoming the de facto standard, with support for just about every major platform out there.

But FetchContent / ExternalProject in CMake is super convenient and works really well if you just have a couple simple dependencies.

Meson's Wraps are pretty useful for including and building dependencies across different OSes.

We migrated netpanzer from Scons to Meson - that was a lot of work (which I didn't do), but it actually integrates with CLion now, builds on win/Linux easily, and builds fast with Ninja.

Scons wasn't that bad, though, I just feel like the build script being turing complete was a pain.

Also Meson doesn't want to just output a binary in your source root. It insists to put it in a build dir, unlike scons.

> Spack cons. Not as well-suited for general-purpose development

While I would not use Spack (or any package manager) to drive the usual hack-build-test development loop, Spack does provide at least two mechanisms to support that kind of general-purpose development activity: "environments" and "views".

Given the list of build systems includes SCons, I'd expect to see waf (waf.io) here.

> Requires rebuild all dependencies are every machine

Regarding vcpkg, this hasn't been true for a while.

https://learn.microsoft.com/en-us/vcpkg/users/binarycaching

vcpkg is the only reasonable one. But I've been burned too many times by libraries staying outdated for months. So I'll stick with manually managing my libraries and also avoiding cmake. Still the best way IMO

Is it weird that the list doesn't include plain old Linux package repositories?

Downloading the dev version of libraries is ancient history.

Although you mention XRepo in the list of package managers, you don't mention XMake in the list of build systems.

The new bzlmod mechanism from Bazel can be count as a kind of package manager.