Bad feeling ...

I don't think `distcheck` is all that important for CMake because…the source tree *is* the tarball; there's no intermediate step which bundles everything that needs re-verified

> I'd say that at least on the Unixoid side Makefiles are still the predominant backend being used

I'd be very surprised if Ninja were not the most popular generator these days. I believe Fedora has switched its default generator at this point at least? I know Visual Studio's integration prefers it.

> And the Makefiles it generates are sub par compared to what automake generates.

Oh, I don't think anyone is going to argue that CMake's Unix Makefiles generator is anywhere near optimal. There are a number of reasons for it. The most important is that autotools and CMake are different build *systems* even though they do share support for a common build *tool* as an output. Because CMake also supports IDEs with…rather restrictive ideas on what is possible, CMake's model for the build is quite different than autotools'. The build tool is easy to define: it is a build graph executor. Make, ninja, msbuild, just, rake, build2, boost.build, bjam, scons, tup, etc. are all "build tools" that execute a build graph. The build *system* is where things get interesting (for me). Some build tools are also build systems: build2, boost.build, scons, tup. This is the layer which defines things like "what is a target" and "how do targets relate". autotools and CMake both execute at this level and "compile" their input language to something the target build tool understands. This does not mean that build systems expose everything that the build tool supports (e.g., CMake does not allow users to write their own ninja rule statements because…what does that even mean for its other outputs). Of course, some build tool support may have additional features as long as it doesn't conflict with the overall model of the build system itself. For example, CMake's Ninja generator can drop some dependencies other generators need to support the semantics CMake guarantees if it can prove to itself that they're satisfied in other ways.

Now, there are ideas to rewrite CMake's Makefiles output to be more like Ninja: one global graph without per-directory entry points and without the per-target subgraph recursive instance. This would allow the Makefiles generator to do the same pruning of unnecessary dependencies that Ninja does. But because it was following the IDE model of "the build graph is a series of targets; each target's subgraph is an independent entity", we have the non-optimal behavior of "if A links to B, B must link before anything in A starts" because that is how CMake guarantees things like generated headers in B are available when A starts compiling[1].

So, in short, I think CMake tool a more general approach to build systems and its Makefiles output is suboptimal because of that. But because we now also support the Ninja generator which is, IMO, strictly better (unless one needs a job server for nested builds), restricting the scope to the Makefiles output of each is not a fair comparison.

[1] The link dependency can be dropped if A's custom command dependencies are a superset of B's custom command dependencies: any header or whatever B ends up generating is already in A's graph.