C++ Package Managers: The Ultimate Roundup(moderncppdevops.com)
moderncppdevops.com
C++ Package Managers: The Ultimate Roundup
https://moderncppdevops.com/pkg-mngr-roundup/
14 comments
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.
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.
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.
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.
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.
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.
There is also `spack develop`, on which people are building hack/build/test loops. You can `spack develop` any package in spack, and easily build with a modified version of something.
See also https://github.com/sandialabs/spack-manager.
See also https://github.com/sandialabs/spack-manager.
> 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
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.
Downloading the dev version of libraries is ancient history.
Linuc package repositories require root rights.
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.
Also if you use it, make sure not to rely on Conan center. Their outages can ruin your week.