Why use a package manager with CMake?

While using CMake's ExternalProject_Add directly can have advantages such as compile flags that match exactly, correctly configuring packages is not always trivial. Furthermore, package managers allow you to reuse dependency sources and binaries between projects, leading to massively reduced storage requirements. This is true even in package managers like vcpkg that build from source, as they only download sources once (and build once per configuration to generate binaries) and not once per build folder (and per configuration for binaries). And those savings can be significant, especially with dependencies like Qt that are several gigabytes in size. Analogously, you also save a lot of time.

TL;DR:

  • Ease of use
  • Reduced storage requirements (if you use a library more than once)
  • Reduced build times (if the package manager has binary packages or you use a library more than once)

If you have multiple (independently built) projects, and they use a lot of the same libraries, a package manager like hunter or vcpkg will compile and store libraries only once (per build platform), saving build time and disk space.

But if your projects are built together, and you cross-compile for multiple platforms (Windows x86, Windows x64, macOS, Linux, iOS, Android (4 different ABIs), WebAssembly, etc.), you indeed may be better off using FetchContent or ExternalProject directly.

For me it was the second case (Scapix project), and in the end I created a small and very simple "package manager" (cmodule) specifically for this case: it only shares downloaded and unpacked library sources, while builds are performed as part of the overall project build.

Tags:

C++

Cmake