I think a build system should always allow to convert its build description to a bash file that contains a more or less linear account of all actions needed (without support for incremental builds). Now if every library were distributed with such linear script, the user is guaranteed not to get stuck in obscure build problems. And of course, they can first try the official incremental route (cmake in this case) if they like.

Assuming that linear account works.

Most of the build issues that a user will face is there system not matching the developers.

We can have pretty complicated logic (arbitrary logic in most build systems) for probing the build system, and much of this logic will inevitably get lost when compiling a linear script.

Once you put all of the complexity in the compiled script, I don't think you've gained anything over "make clean ; make" (or equivelent)

Maybe but bash is hardly less weird than cmake, especially for Windows devs.

Creating your own build tools becomes unmaintainable by anyone else. People do it all the time, and pay the price when they have to change their builds. There is a reason CMake is used by a lot of projects, it's not somehow due to everyones incompetance.

If the build system was a library called from a popular scripting language, it would only take a few minutes of reading the API docs before it builds could be modified. Also, there is a niche for new build systems: one-off projects that "don't matter." If you want to introduce a new build system, your first target market could be throwaway point-a-to-point-b projects and then you could expand outwards from there.

That's basically Gradle and if you think cmake is bad you haven't seen some of monstrosities that can be created when you open up a whole programming language.

From what I've seen cargo gets most of the parts right. You can have a programmatic pre-build script bit can't take over the whole building process.

Yes, with gradle you can create true monstrosities — and even my own projects aren’t free of those, sadly, because sometimes there’s just no alternatives.

Here’s a few examples:

Dynamically using git describe to determine version and build number (which is actually just the # of commits that ever occured, to allow reproducable builds)

    versionCode = cmd("git", "rev-list", "--count", "HEAD")?.toIntOrNull() ?: 1
    versionName = cmd("git", "describe", "--always", "--tags", "HEAD") ?: "1.0.0"

Putting git infos into certain classes

    buildConfigField("String", "GIT_HEAD", "\"${cmd("git", "rev-parse", "HEAD") ?: ""}\"")
    buildConfigField("String", "FANCY_VERSION_NAME", "\"${fancyVersionName() ?: ""}\"")
    buildConfigField("long", "GIT_COMMIT_DATE", "${cmd("git", "show", "-s", "--format=%ct") ?: 0}L")

Using string interpolation to change the output file to include the version

    setProperty("archivesBaseName", "Quasseldroid-$versionName")

But the worst part is that often on StackOverflow you only find ugly hacks adding custom tasks, removing tasks, modifying them, etc with ugly hacks.

And even worse, sometimes there’s just no good alternative at all.

Which is why gradle took so long to clean up some parts of their API, or introduce parallel builds.

Buck and Bazel work this way. The language is Python (with some optimizations). However, the build is fast because Python is only used to describe the build graph.

SCons in particular is along the lines of the latter, in that its. But it never really caught on, IMO.

Probably one of the biggest features in a configure/build/packaging software package is ubiquity, IMO. Ideally C/C++ would have had a prescribed-but-not-required thing like cargo/setuptools/go get/etc. IMO CMake is probably the least bad offering these days.

I read about scons, loved it, tried to use it, gave up. Tried cmake, found it workable but super confusing. Went back to make.

To be fair, CMake's language was first created somewhere back in 1996. It's quite old at this point and is basically in the "sunk cost fallacy" range of existence.

No, a good (not turing complete, easy to use, with types) DSL is a good thing. Meson does it right.

I'm not sure what you mean. If for whatever reason I need to set up a big C/C++ application so that it can compile on diverse systems, CMake is one of my best bets for getting that to happen. If anyone would like to suggest a better option I would gladly switch, but as it stands I think CMake is pretty useful to know about.

I'm not arguing that it doesn't do what it was designed to do. I'm arguing that it is a grotesque DSL with bizarre design choices. CMake would have been better off as a cross-platform library that didn't re-invent concepts that other programming languages have already gotten correct, and instead focused on making the build system be cross-platform.

I’ve mentioned the same thing before and ironically, CMake was developed in the course of building medical imaging software[0] that was using Tcl, a flexible, embeddable language, but then decided to roll their own ad hoc language in this case. They left a LOT on the table with that decision, I think.

[0] https://en.wikipedia.org/wiki/VTK

I think the op's point is that it was not necessary to invent a new programming language for this. You could write a library for existing languages (probably with a custom entry point) that does the same thing, but without a new and confusing syntax.

Bazel works very well for C++ applicatios. Cross platform builds are well supported.

bazel can’t even build static libraries

https://github.com/bazelbuild/bazel/issues/1920

False. The bug above represents a nuanced case.

Meson?

Scons came to prominence around the same time as CMake and took that approach, but seems to have been less popular.

CMake is very powerful but unlike most things there’s no underlying principle or theory that when you grasp it, everything just clicks, and you also can transfer the knowledge to other languages. It’s just a matter of memorising lots of tricks and special cases.

This is mostly true about the language but not about the way build artifacts and their dependencies work. That part is pretty solid.