Investigate other package managers

[ekilmer]

vcpkg is nice when everything is packaged correctly, however it is very difficult to share the result of a single pre-compiled package with someone else to install into their existing set of packages. This design is nice to ensure maximum compatibility for a single machine by hashing almost every component that goes into building the package (compiler, source code, patches, cmake scripts, dependencies, etc.), but it is very difficult to share pre-compiled packages by themselves.

On the other hand, package managers like Homebrew get away with compiling a package once (and any dependencies) and distributing the result to all macOS users on the same OS version. Mac is relatively easy to do this because there is really only a single target operating system. Linux is more difficult if you aren't careful about libc and lib(std)c++ compatibilities, but Homebrew seems to support Linux, and we could only officially target Ubuntu 20.04.

The nice thing about vcpkg is that you only need to specify the CMAKE_TOOLCHAIN_FILE to choose which dependency set you'd like to compile against. With Homebrew, it's more of a global installation (kind of), which would require manually specifying package directories like -DLLVM_DIR=/usr/local/opt/llvm...

[mrexodia]

You can consider switching to a CMake "superbuild" using ExternalProject_Add. I did a (successful) experiment for remill like this: https://github.com/mrexodia/cxx-common-cmake

The advantage over vcpkg is that you get the folder cxx-common-cmake/build/install that contains all the dependencies. You can copy this folder to other machine and all you have to do is use cmake -B build "-DCMAKE_PREFIX_PATH=<path-to-cxx-common-cmake>/build/install to allow find_package to find your dependencies.

The "disadvantage" is that your dependencies need to produce correct CMake packages and this can be a bit of a challenge. For example xed.cmake requires a bit of hackery: finding python, fetching mbuild, fetching/building xed and finally a custom XEDConfig.cmake that allows find_package(XED).

In my opinion the whole caching mechanism of vcpkg is utterly useless and does not at all scale with "real world" use cases. For example building LLVM can take 40 minutes and it doesn't make a lick of difference what compiler version you use to build it. For vcpkg the compiler version is included in their caching hash and would trigger a useless rebuild. The approach described above does not do anything for caching. You would just produce a release for each platform/dependency version and you can then use those binary packages.