There are mature solutions for building C/C++ programs which check for dependencies and provide a high quality configuration setup. Think of GNU Autotools. It is often blamed to be too complex, but this complexity is essential, not accidental. You do not want to abstract away details a C/C++ maintainer cares about.
It’s not that autotools is complex - rather, most of what it does hasn’t been useful since nineties, and when it doesn’t work - which is quite often when it’s being used on a platform a given piece of software hasn’t been tested on - makes fixing the build harder compared to hand-written makefiles.
Right, but that still doesn't solve the problem of actually distributing the library in the first place.
As a library author you basically have to wait for distributions to start shipping it, or make users manually install dependencies (and then make the build work with libraries installed into /usr/local).
Right, this is an extraordinary pain point as a library author which writes libraries in C or C++.
That's assuming the distro even does package it up. Because beyond Archlinux packaging, packaging up a DEB is painful. RPM is somewhat less painful, but you still need to contend with N distros. Your lib depends on lets say 4 other libraries, perhaps some of the GTK ecosystem of libraries. Good Luck!
Autotools doesn't help you solve the issue of you needing version X.Y when Z.X is installed, neither do RPM/DPKG/etc.
When you go to build C projects, there's usually a long list of instructions, per distro/os to set the environment up correctly.
Compare that to a Rust project where you git clone and cargo build to get going. No instructions needed, no insanely complicated esoteric m4 macro system, or ad-hoc programming language (looking at you CMake), and snowflake package manager needed.
Meson is the only C/C++ build tool I know of that solves the issue of building complex C/C++ programs with dependencies sanely. Especially in the case where both your application and your dependencies are unreleased as of yet, as is the case with Gnome and KDE applications as they are developed.
Not really, because the amount of provided package versions is very limited. You won't get an update unless the package maintainer (who is likely not the library owner) provides an update.
That's a feature, not a bug. I want to rely on well tested, stable, mature libraries that receive security updates and don't change for the next 3 to 5 years.