Autotools does do all of those things. I'm not a particular fan of it either, but when I'm packaging software for a Linux distro then I'd rather see autotools or cmake being used instead of some crappy custom build system that will require patching to make it work.
There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used, so there's a rather large barrier to entry.
Whenever "configure" is looking for a fortran compiler in a clearly non-fortran program, one has to wonder why no one fixes the configure scripts. From all I learned it is, because the underlying scripts are close to unmaintainable. So from that perspective, a better build tooling should be a high priority.
No one fixes the configure scripts because they're thousands of lines of code in about three different archaic languages that nobody knows or cares about.
autotools is pretty great for the end-user who wants to compile your code or the distributor who wants to package it up for Debian or whatever.
It’s a crawling horror for the programmer that wants to use autotools as the build solution for their code however, which is the topic under discussion.
This only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).
Not really. the end user doesn't need autotools installed actually. To build the configure script from the "configure.in" file, you need autotools. Go ahead and try!
It's not that hard. I recently had to debug a memcached configure.in script. But, I consider myself a C programmer, so that fact might be source of bias.
There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used, so there's a rather large barrier to entry.