b2 / bjam, a custom build tool that was bootstrapped via a script that just builds.

If they have a tool that builds it, why require CMake? Why add an unneeded dependency?

One huge advantage: if your project already using CMake then you'll be able to include exact version of Boost library into your project as git submodule. Then it's will be built hassle-free across all of your toolchains and platforms.

This will of course require some proper configuration on Boost side, but no doubt they'll handle it.

Well, partly because b2/bjam is aboslutely awful and obtuse, etc. etc.

I did some semi-serious experimenting with it at one point and it was just... well, awful. It basically did very few things right.

(BTW, don't take this as criticism of the authors of said system. I just don't "we" had learned enough and infrastructure was incredibly far behind what we have now. So I don't "blame" them in the least. It's just a product of its time.)

I'm not sure what it's like to maintain the build system, but my experience with CMake as a user has been great. It can even generate makefiles for nmake so I can do Windows builds from the comfort of the Windows command line, although I mostly use it under Linux. Under Linux, I've found that CMake is much friendlier when it comes to helping you fix your dependencies than autotools-based build systems.

It probably is nicer than autotools, but my experience with build systems for other languages makes CMake feel like a pile of hacked-together macros. My last company used it for a large codebase and we spent nearly as much time maintaining the build scripts as we did developing features.

Please be specific. What other build systems do you have experience with?

(Because, honestly, I've never heard of a "good one", but there are "less bad ones".)

Cargo and Go's build tool are great.

If all you want to build is Rust and Go code... what happens if you have a project composed of multiple languages?

FWIW, I like "cabal-install", the Haskell equivalent of cargo. It also suffers from the same problems as soon as you start to use multiple languages in a project (except C, that's quite well supported). I stress the word "project". If a "project" to you is just a single language then I'm, first of all, happy for you... Unfortunately that's not the reality for many of us, and THAT is why we need build systems.

EDIT: Point being: A language-specific build system can be great, but as soon as you get a big project with multiple languages it leaves you, the Master of the Build, with a big problem because you suddenly have to incorporate every $OTHER_LANGUAGE into the build... somehow. All of that integration is on you and is specific to your situation.

A build system on the other hand leaves each language implementation with a simple problem: how do I integrate with build system X? One that's settled it works for everyone using build system X, so we're not duplicating that huge amount of effort you would put in in the language-specific-build-tool situation.

(Obviously, this imaginary perfect build tool "interface" is highly non-trivial, but that doesn't mean we shouldn't strive for it.)

There's certainly a place for invoking each project's build tool and stringing together the resultant packages into a tarball, docker image, or nix package. CMake doesn't do this; it gives you a (shitty--for reasons mentioned in other posts) framework for building an ad-hoc build tool for your project, never mind that 99% of projects in any language could be built the same way (which would minimize maintenance work and learning curve).

Yes, but "stringing together" == "non-parallelism" | "unmaintainable because shell scripts". This can kill projects. I'm not even joking.

EDIT: Again, I'm not saying CMake is perfect, but then you haven't offered anything better, so... NYAH? Do you have something better? It's easy to complain about build systems (I do it all the time), but not so easy to come up with something better. Btw, have we dispatched the single-language assumption at this point? (Because, unless "your" language is C or C++, it's not going to happen unless POSIX is miraculously displaced).

There's nothing about invoking build tools that precludes concurrent builds or which requires ad hoc shell scripts (although "unmaintainable scripts" is an ironic defense of CMake, since it's subject to all the same criticisms).

Alternate solutions include Docker, Nix, or even plain makefiles depending on what your artifact needs to be.

Posix is unrelated to invoking multiple build tools and assembling their results.

Well, at the moment your best bet would be "Bazel" I think. It has rules for many languages.

I try to do something similar with my own project https://github.com/jachris/cook – it's not ready though, but you can take a look at it.