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