3 ms·

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

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.

PaulDavisThe1st 3y ago
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.
- ho_schi 3y ago
  https://mesonbuild.com/Wrapdb-projects.html 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.
- tempodox 3y ago
  If you download the sources, can't you compile them in whatever configuration you need?
  - PaulDavisThe1st 3y ago
    Yes but that's not a package management system.
pjc50 3y ago
> 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.
ho_schi 3y ago
I suggest changing the build tool. Meson improved C and C++ a lot: https://mesonbuild.com/ 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 https://mesonbuild.com/Wrapdb-projects.html
- boris 3y ago
  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 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 https://build2.org/faq.xhtml#why-package-managers
xcdzvyn 3y ago
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.

PaulDavisThe1st 3y ago

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.

ho_schi 3y ago
https://mesonbuild.com/Wrapdb-projects.html 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.
tempodox 3y ago
If you download the sources, can't you compile them in whatever configuration you need?
- PaulDavisThe1st 3y ago
  Yes but that's not a package management system.

pjc50 3y ago

> 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.

ho_schi 3y ago

I suggest changing the build tool. Meson improved C and C++ a lot: https://mesonbuild.com/ 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 https://mesonbuild.com/Wrapdb-projects.html

boris 3y ago
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 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 https://build2.org/faq.xhtml#why-package-managers

xcdzvyn 3y ago

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.