[superxpro12]

As a c/c++ cmake user, cargo sounds like a utopia in comparison. It still amazes me that c/c++ package management is still spread between about 5 different solutions.

IMO, the biggest improvement to C/C++ would be ISO defining a package manager a.la pip or uv or cargo. I'm so tired of writing cmake. just... tired.

[hedora]

People that don't understand make are destined to recreate it poorly, and there's no better example than cmake, imho.

Here's my arc through C/C++ build systems:

- make (copy pasted examples)

- RTFM [1]

- recursive make for all sorts of non-build purposes - this is as good as hadoop up to about 16 machines

- autotools

- cmake

- read "recursive make considered harmful" [2]

- make + templates

Anyway, once you've understood [1] and [2], it's pretty hard to justify cmake over make + manual vendoring. If you need windows + linux builds (cmake's most-advertised feature), you'll pretty quickly realize the VS projects it produces are a hot mess, and wonder why you don't just maintain a separate build config for windows.

[1] https://www.gnu.org/software/make/manual/

[2] https://news.ycombinator.com/item?id=20014348

If I was going to try to improve on the state of the art, I'd clean up a few corner cases in make semantics where it misses productions in complicated corner cases (the problems are analogous to prolog vs datalog), and then fix the macro syntax.

If you want a good package manager for C/C++, check out Debian or its derivatives. (I'm serious -- if you're upset about the lack of packages, there's a pretty obvious solution. Now that docker exists, the packages run most places. Support for some sort of AppImage style installer would be nice for use with lesser distros.)

[duped]

cmake exists not because people didn't understand make, but because there was no one make to understand. The "c" is for "cross platform." It's a replacement for autoconf/automake, not a replacement for make.

> If I was going to try to improve on the state of the art

The state of the art is buck/bazel/nix/build2.

[NekkoDroid]

Do note that a (I think standardized) common package specification is being worked on called CPS (Common Package Specification). It doesn't specify how you get your dependencies, but it does specify how they should look like, so that your actual package manager does not need to care about the build system specific formats as it currently does.

[steveklabnik]

Worth reading, from a year ago: https://www.reddit.com/r/cpp/comments/1hgpz0y/wg21_aka_c_sta...

It seems CPS is still being worked on, but not under the standardization of the committee, due to the above.

[enriquto]

cmake is a self-inflicted problem of some C++ users, and an independent issue of the language itself (just like cargo for rust). If you want, you can use a makefile and distribution-provided dependencies, or vendored dependencies, and you don't need cmake.

[duped]

imo the biggest single problem with C++ that the simple act of building it is not (and it seems, cannot) be standardized.

This creates kind of geographic barriers that segregate populations of C++ users, and just like any language, that isolation begets dialects and idioms that are foreign to anyone from a different group.

But the stewards of the language seem to pretend these barriers don't exist, or at least don't understand them, and go on to make the mountain ranges separating our valleys even steeper.

So it's not that CMake is a self-inflicted wound. It's the natural evolution of a tool to fill in the gaps left under specified by the language developers.