Hacker News Reader

Comment by antoineMoPa | Hacker News Reader

For me, it's the fact that there is no standard package manager for the language. Finding the right linker/include args is soooo not user-friendly. Also, these `-I` and ˋ-l` flags can differ across platforms (and so can the installation procedure for these libraries). Yesterday, I tried to run an old project of mine developed on linux, but this time on a mac. First, the linker complained it could not find -lglm, I had to search a bit to find out that this is gl math. Then I searched this in homebrew, I also looked at different package managers. The low quantity of packages available surprised me. The most interesting package manager looked like it required python. Can't the community build a package manager in their own language? Anyway, at this point I gave up for the day.

I love the language overall. Seems like standard & easier management of dependencies and compiler flags would help it thrive again.

View on HN

You can't have an effective package manager for a compiled language unless the package manager is actually a part of your own build system.

The example I always use: you want to use libfftw ("Fastest Fourier Transform in the West"). But the library can be compiled with (at least) two options: use floats or doubles, use threads or not. That creates (at least) four possible variants of the final library.

The only way to address this (and IIUC, Cargo for Rust does this) is to somehow have the pkg manager be a part of your build system, so that you end up with a local copy of the library, built as required.

https://mesonbuild.com/Wrapdb-projects.html

Meson did that. You can use system packages, define your own dependency, use sub-projects (custom build option a, you mentioned) or readily available from WrapDB.

If you download the sources, can't you compile them in whatever configuration you need?

Yes but that's not a package management system.

> no standard package manager for the language

Kind of an uphill struggle this one, because there's no standard implementation of the language, nor is there a standard build system. You have to deal with multiple vendors, one of whom is Microsoft and many of whom are unwilling to change rapidly.

Tbqh after figuring out make + pkg-config, it's kind of zen. C/C++'s unique dependence on the system's package manager for libraries is weird, but I can't say I hate it.

I suggest changing the build tool. Meson improved C and C++ a lot:

https://mesonbuild.com/

The dependency declaration and auto-detection is nice. But the hidden extra is WrapDB, built-in package management (if wanted):

    https://mesonbuild.com/Wrap-dependency-system-manual.html

https://mesonbuild.com/Wrapdb-projects.html

As the name suggests, this wraps the whatever build system that the dependency is using rather than replacing it with Meson. Say if you depend on Boost and Qt, you will end up using both Boost Build and CMake in addition to Meson (most likely there will be a couple of more build systems if you are also building Boost's and Qt's own dependencies such as ICU). This has two major drawbacks:

1. The build in step-by-step rather than end-to-end. Meaning that you first build Boost completely, then Qt, and then your application. With an end-to-end build you would build everything with a single build system invocation with the build system "seeing" the entire build graph. In particular, this would allow you to build only what's necessary and faster.

2. If something goes wrong in one of these dependencies, you better be prepare to become an expert in whatever build system it uses.

If you want a true Cargo-like experience in C++, a better option would be build2, which replaces rather than wrapps the build system (and, yes, it has Boost and Qt packages): https://build2.org

For more details on what an end-to-end build can give you, see: https://build2.org/faq.xhtml#why-package-managers

Reply on news.ycombinator.com