3 ms·
I know this is slightly annoying knee-jerk reaction but it would be remiss not to mention vcpkg [1] whenever C++ dependencies are brought up. In practice vcpkg
by quietbritishjim 6y ago
I know this is slightly annoying knee-jerk reaction but it would be remiss not to mention vcpkg [1] whenever C++ dependencies are brought up. In practice vcpkg has by far the most packages of any C++ package manager. For example, it's unusual to find any one of opencv, grpc and QT5 for Windows, Linux and Mac in any other C++ package manager, let alone all three.
Unfortunately I'm not enough of an expert on the alternatives to make a proper comparison, but it seems to me that vcpkg works better with whatever build system the packages natively prefer to be built with (e.g. although vcpkg is CMake-based it can build Visual Studio projects on Windows and make-based libraries on Linux) whereas following links in the OP's article takes me to a zip file full of meson.build files that seem to have been written from scratch for the library. Using the library's own build system directly seems like a much more managable long-term solution. Also, vcpkg's policy of putting all the ports into its git repository, while it does have disadvantages, does make it very clear everything that vcpkg is doing and needs to know to build something (e.g. [2] for grpc).
Edit: A partial comparison of vcpkg with Meson WrapDB and Conan Centre:
* Meson WrapDB lists just under 145 packages, although some of them appear to be empty (e.g. grpc, libtiff). As mentioned above, it seems that you need to re-implement the whole build system for a library in Meson for it to be included. I found that the package data is on github e.g. for spdlog [3]
* Conan Centre lists 583 packages, so it seems like a much better choice than Meson. The way to specify different configurations look awkward to me - they mix up decisions that you probably want to share across your dependencies (e.g. platform, static vs dynamic) with library-specific stuff; but maybe I just don't understand them properly.
* vcpkg has 1509 ports, including several quite tricky ones like grpc on Windows and QT as mentioned above. The configuration stuff is split over places in a way that makes sense to me: triplet files contain global options like static vs dynamic and even cross compile options, the portfile itself contains any package-specific tweaks, and feature packages allow extra features in ports (e.g. I can vcpkg install opencv[eigen3] to mean "include eigen3 support in opencv3", which would also update the list of transitive dependencies).
[1] https://github.com/microsoft/vcpkg https://github.com/microsoft/vcpkg
[2] https://github.com/microsoft/vcpkg/tree/master/ports/grpc https://github.com/microsoft/vcpkg/tree/master/ports/grpc
[3] https://github.com/mesonbuild/spdlog/tree/1.8.0 https://github.com/mesonbuild/spdlog/tree/1.8.0
- virtualritz 6y agoCuriously, more and more Rust crates, mainly wrapper ones that depend on C/C++ libs, pull those in via the `vcpgkg` crate[1] in their `build.rs`. And I also saw some that then use `pkgconfig`[2] as a fallback. I already fixed several `vcpgkg` ports as I started using this myself in several of my crates. 1. A package manager is only ever as good as its coverage of people's needs - packages wise. Forget usability, CLI, etc. If it covers the packages I need (and can actually build them) I'm happy to bite those bullets. 2. Having a single package manager for a language X certainly helps with 1. While any extra one that someone comes up with because they do not like the CLI/UX/"principles" of the existing one or whatever is a detriment to 1. [1] https://docs.rs/vcpkg/0.2.10/vcpkg/ https://docs.rs/vcpkg/0.2.10/vcpkg/ [2] https://docs.rs/pkg-config/0.3.19/pkg_config/ https://docs.rs/pkg-config/0.3.19/pkg_config/
- pjmlp 6y agoI love vcpkg, specially since it is written in C++, a package manager should use the language it serves.