Hacker News Reader

Comment by umvi | Hacker News Reader

Honest question because I don't know how cargo works.

How would a package management system for C++ work?

Would there be a centralized repository containing shared objects, static objects, and header files of all the packages? Who would pay for the hosting? How would you track which libraries are compatible with which compilers/OSes/architectures?

Seems like at this point it would be a herculean effort to create cpppm because of how fragmented the compilers/support is across systems. And so it would be a broken piece of garbage so people wouldn't use it.

View on HN

> How would a package management system for C++ work?

> Would there be a centralized repository

> How would you track which libraries are compatible

> Seems like at this point it would be a herculean effort

This is not a bizarre or impossible idea.

Besides the plethora of package managers in more modern languages, there are in fact, actual real-world C/C++ package managers: Conan [1], Buckaroo [2], vcpkg [3], Conda [4], cget [5].

However, it's much like Go before its maintainers did anything: it's the Wild West and every day brings a new package manager.

Having some consensus, standardization, common concepts, or direction would help C++ adoption/usability enormously.

[1] https://conan.io/

[2] https://buckaroo.pm/

[3] https://docs.microsoft.com/en-us/cpp/build/vcpkg?view=vs-201...

[4] https://conda.io/en/latest/

[5] https://cget.readthedocs.io/en/latest/

A central repository is helpful but not strictly necessary. I just want to have a config file where I specify what version of a library I want and where the build system can fetch it and have that work recursively for dependencies.

> the build system can fetch it and have that work recursively for dependencies

Which build system? CMake? SCons? GNU Make? Unix Make? Autotools? Visual Studio Solution?

Cpp libraries are far from having a standardized build system. And without a standardized build system, you can't do what you describe.

I suppose you could say "CMake is the standard" and then only support CMake-compatible libraries, but again, that leaves hundreds of packages out of reach.

And why are these build systems necessary in the first place? They mostly exist to work around the lame library ecosystem, where you never know what's installed or where to find it. Solving the "library problem" would presumably render these tools and their horrible complexity obsolete.

If there were some type of system where library A says it depends on library B (via a URL or some other non-centralized thing), and the compiler knows how to resolve this, then you don't need 90% of the features these tools provide. You still need build parallelization and maybe detection for non-standard compiler features, but this is a much smaller and simpler problem.

> And why are these build systems necessary in the first place?

Because C/C++ compilers are fragmented. And because C/C++ is not very portable. If building for windows -> pass a bunch of -D flags to the compiler. If building for Linux, pass a different set of -D flags. Different compilers require different arguments.

> If there were some type of system where library A says it depends on library B ... and the compiler knows how to resolve this

Here's the crux of the problem. There is no organization that owns or maintains C++, unlike Rust. With Rust, there is only one compiler - rustc. With C++ there are at least 5 major ones maintained by 5 different (competing) organizations.

There's no way to do package management in C++ without massive build system rewrites. Consider:

I write a new C++ package called CoolCrypto. It depends on libssl. I wrote my package in CMake, libssl uses autotools. Barf, the package manager only speaks CMake and gives up.

> And why are these build systems necessary in the first place?

Because depending on the use case you generally need to build the same software in a lot of different configurations : debug / release runtimes on windows, various sanitizers, static / dynamic / dynamic with LTO, you also want to build some files only on some platforms, you want your users to be able with / without tests / examples / implementations of various types (e.g. enable / disable network protocols or media codecs at build time for the two most common use cases I know), enable / disable profiling or coverage or tracing support... add a flag for having split debug info but you need to disable it if your users run ubuntu 16.04 because here it's broken, add a flag for linking with lld but you need to disable it on macos because it's broken, change debug mode to -Og if you're on a CI machine because -O0 takes too much space and you fill the Travis CI vm, except if you're on a worker with a recent enough toolchain to support -Wl,--compress-debug-sections=zlib

e.g. look at the configurability of something like ffmpeg : https://paste.ofcode.org/zBhsKWiSk3Gn73bkgfA9Yk

or qt : https://paste.ofcode.org/wmZZX9emiNr2uPksceZNz6

or one of the project I work on - most of the config flags here were added after the request of some users who wanted to be able to make a leaner build in some specific case ; making multiple shared libraries is a no-go first because then your users complain that they don't which of the five libraries they have to add to their system, and also because you loose LTO and have a lot of duplication of template instantiations (or monomorphized generics as it is said in Rust parlance): https://github.com/OSSIA/libossia/blob/master/cmake/OssiaOpt...

You rarely have complex problems with simple solutions.

Reply on news.ycombinator.com