Just to reality-proof that: Redis managed to survive 7 years without autotools so far, using similar techniques, you just type "make" regardless of the unix system you want to compile Redis with. No major complexity was faced in order to do so, however Redis depends on nothing externally if not libc. For software projects with many external deps it may be worth to use autotools instead.
To add another example: spiped is 6 years old and should build on any POSIX system with the Software Development Utilities option, /dev/urandom, and OpenSSL. Over the years I've collected a handful of workarounds for not-quite-POSIX systems, but the "check if we need any workarounds" step of the spiped build is still much faster and simpler than using autotools.
People can really easily abuse the Makefile ecosystem and write complicated, difficult to read, spaghetti builds. If something fails somewhere in the m4 macro forest while building on your specific machine, you're hosed for potentially hours or days while trying to figure it out so you can just build the damn project. The whole point of this kind of tooling should be to take some of the heavy lifting out of getting source code built, not add extra complexity to a project.
I've been working on and off with Make, C, autoconf, etc for ten years. Maybe if I were a full-time C or C++ person I'd have less trouble with this, but it seems rather excessive. The thing that most discourages me from contributing to certain open source projects is when I clone the repository and the build fails and I can't get the project to build in an hour or less of build-debugging time (and I'm not on a weird setup, I'm on a modern Lenovo with Debian).
Quick, how do you install redis to a different prefix? Everybody knows `./configure --prefix=...` (or if they forget, there's `./configure --help`), `make PREFIX=...`, not so much.
I've seen quite a bit of "./configure"-less software use "PREFIX=/foo make install" (or some variation thereof) for that (something which I have to address as part of maintaining various Slackbuild scripts). This is usually part of the compilation/installation documentation. If not, install targets are usually simple enough that I can glean which environment variable the Makefile is using to control the installation prefix.
Worst case scenario, the SlackBuild I'm writing has to include some call to patch or sed in order to tweak the installation path, or I just have to cp the build output into the package's root directory (something which I'll likely have to do when I get around to updating the CouchDB SlackBuild, but have been putting off since 1.6.x works well enough on Slackware).
This was my own thought when reading the article: how exactly do you use pkg-config to find libs+headers without autotools (or at least an m4 processing step)?
You can run pkg-config yourself, the m4 macros are just for convenience. Look at the shell the macros expand to to see how to do it.
Though I don't see the point in reinventing your own build system, exactly. Some people I trust seem to be getting into Meson these days but I havent tried it.
