I 100% share your feelings.
What is often forgotten is the ecosystem.
To build a cxx project you'll probably need to learn CMake and ninja; maybe Buck or Bazel too. If your project has eternal dependencies you may have to figure out yourself how tl link everything together using whatever build tools the authors were using. For docs, you'll have to learn and use doxygen; for style formatting, something like a clang-format and its presets and options; for linting, something like clang-tidy or cpplint, etc. For testing, probably catch2 or one of similar frameworks. There's no universal concept of "package" or "version", you're completely on your own here; most open source cxx repos that have dependencies just add them as git submodules.
In Rust, cargo build to build, cargo doc to generate docs, cargo test to run tests, cargo publish to push your crate to the index; cargo fmt to format the code and cargo clippy to lint it - that's it, we're done.
I've been using Rust for ~3 years now, and have been trying to learn C++, but I've been so spoiled by the entire Rust ecosystem's user friendliness that it's a very daunting task.
Man, that type of stuff don't motivates anyone to learn a new language. If all what we should do it is code a solution and deploy with one command, oh God, will be a dream.
But no, beyond all this clusterfuck, by doing cloud stuff will be need probably Docker too, Kubernetes. Maybe ansible too? Oh, no, your team use terraforms.
D:
Would that a git for build tools would come along.
That is, something so compelling and sufficiently licensed that it quells the discussion in a jiffy so that the focus can be on getting work done.
For git, I felt kind of sad that "linus branding" helped it to beat out mercurial. git's UI is kind of monstrous (even linus admitted that). It's one of those rare technologies where a bad UI is branded as "you're just not smart enough to understand it".
Personally, if you're not using magit[1], you should have a look.
Ridiculously powerful; check. Open source; check. Works like a champ in a terminal over SSH; check, check, check.
So, for me, its much worse than just “omg which tool, so many!” because the most used tool is also, in my personal opinion, terrible.
When you find yourself manually listing the .h files that a c/c++ file includes, learn how to generate .d files (it is in the manual, but stack overflow has some better patterns).
Then, figure out how to use make to automatically generate the list of source files required to build each binary. At this point, your makefile will have surpassed the usability of cmake in my opinion.
Soon after that, you’ll think you need recursive make to deal with vendored dependencies. Instead, read “recursive make considered harmful”.
At that point, you’ll start to hit rough edges, but you’ll be well beyond a “small project”.
Next on my make reading list is the BSD ports system.
I’ve heard bazel is a decent make replacement, but I haven’t used it.
Ninja doesn’t aspire to be one, and cmake/autotools are the reason I decided to go with raw make in the first place.
However, it quickly turns into a morass the moment you want to do something outside of it.
I tried, and I gave up. I ended up coding something similar to make, in python. I just funneled some of my commands to the shell module.
I love how that's one of the things the author listed in their post :)