So what would you suggest in lieu of autotools? The only real mature alternative is cmake, and cmake's main advantage is that it is a cross platform build system. Basically that means it works on windows without cygwin or its equivalents.

If you use something other than cmake or autotools, you're going to end up making the lives of packagers more difficult. If they have to change anything, as they usually do, they're going to have to know how the build system works, and they dont necessarily want to deal with whatever new-fangled build system you're using.

Usually projects using cmake distribute their source code with cmake build scripts because they're taking advantage of cmake's cross plaform features, and cmake generates different source distributions for different platforms. But this does place a burden on the user to have cmake installed. There's a good argument to be made that that's no longer much of a burden, after all, it's just one package manager invocation away. But you have to think about who's downloading a source distribution (as opposed to binaries or checking out the repository). They're people who are compiling from source for esoteric platforms, perhaps and embedded system, where a cmake package might not already exist. They're people like me who are writing their own pkgbuild script because they like to keep their system well organized and not have too many useless packages (like cmake) lying around. They are people creating a new linux distribution who haven't yet packaged cmake but want to package your software.

And in terms of software design, cmake isn't very good, at least in the eyes of many people writing unix systems software, which as far as mature open source software projects written in C/C++ go, is a lot. Don't get me wrong, cmake certainly has the cross platform advantage, and if you're making software that you want to compile on windows, you'd be remiss to not at least seriously look into using cmake (not that it's the only option, you could also opt to lean on cross-compiliation from a unix platform to windows, distributing binaries only, or requiring users to install cygwin, which isn't worse than having to install visual studio if you don't already use it).

But if you're not taking advantage of the cross-platform features, I'd say cmake is pretty awful. Precisely because it's cross-platform, cmake rejects the typical design principles of unix software, instead offering a monolithic build system that requires special scripts to be written for any different tools you want to use, or even any complicated dependencies (for example: SDL). This is necessary because cmake needs to establish a consistent internal interface that can work for both the windows and unix tools. As a result, everyone has to learn how to use the monolithic cmake system from the ground up, and those skills won't be useful for anything else.

In contrast, autotools, known for having a high learning curve, is really not that bad for people who already know unix. If you understand how to use a unix system, you can figure out autotools faster than you can cmake. And you can really know it, to the extent that you feel confident diving in and messing with its defaults, much sooner than you would with cmake.

But of course, ease of learning isn't the only factor autotools integrates with external tools using their standard interface while cmake demands you essentially write a wrapper for them. Autotools is simply more flexible.

I don't like autotools, for the record, but given the options available, I'd probably choose it over any other build system in almost all the places it's used currently and more.