If you like CMake more, that would be a good argument if CMake worked. But it doesn't. So in the choice between the thing that works, and the thing you may like more, please do go with the one that works.
The problem is that more often than not, the autotools don't work.
They were the go-to tools for the portability problems of the mid-late 90s and early 2000s. Unfortunately, since then they have stagnated, and they are now stuck solving portability problems very few of us have. But they don't do much for contemporary portability issues, while CMake most certainly does.
Most recent problems I've encountered are that Autotools failed to build properly with MinGW and Cygwin. CMake worked perfectly.
Since the decline and obsolescence of proprietary UNIX platforms, the main purpose of the Autotools has been effectively removed. Today, the Autotools work on Linux, BSDs and MacOS, but with pretty much everything else having been long obsoleted, the amount of testing on other UNIX platforms is both minimal and completely pointless. Few people care. They are dead. But, they still don't support the most popular platforms of today: Windows, Android and iOS. But CMake does.
Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS, with some dependencies in nonstandard locations, etc… etc…
It could. But it's an incredible coincidence that it's always cmake projects.
Generally on nonstandard installs the others (e.g. scons) won't even run, so portability of the conf is not relevant.
> Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS
what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports (https://packages.debian.org/en/sid/devel/kcachegrind).
I also never had issues with x32 when I used it, nor on freebsd. Can't say for openbsd but I'd be surprised it does not work there - this seems to point that other than a minor path issue things just work: https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5....
Again, project after project that doesn't work under those settings.
I'm not saying CMake itself doesn't work. Though I have run into both "CMake version is too old!" and "CMake version is too new!", which by its nature can't happen with autotools.
The reason it hasn't been seen recently is that there has been no significant development of note for the past 15 years.
Even so, it's still common for the distributed config.sub and config.guess to be outdated. That's the price you pay for embedding stuff in each package, as opposed to requiring the build tool to be provided on the build system just like all the other tools.
If you like CMake more, that would be a good argument if CMake worked. But it doesn't. So in the choice between the thing that works, and the thing you may like more, please do go with the one that works.
E.g. this comment I just wrote: https://news.ycombinator.com/item?id=25702345