Autoconf has been around for years, cmake for much less, yet cmake was able to become the major build system for C++ and get everywhere.

I don't think autoconf has a future - even when it was "the only choice" everyone avoided it if they could. Cmake took over and became the thing everyone knew.

Now if you (like the article) proposing something else you might have a chance. However autoconf has lost.

Autoconf "lost" in the sense that it solved the problems that it needed to solve and is no longer needed.

Autoconf solves the problem of easily porting software to different systems because autodiscovery is its default modus operandi.

Now that we live in a post-innovation world, there is no need to port software: it's either Linux, Mac OS, or Windows.

Except, of course, there is still a lot of innovation going on, and there's a lot of porting and cross-building that happens outside the the web domain, and a heck of a lot of things that are none of the big three development hosts.

CMake is starting to converge towards what the autotools have provided for some decades now, but it's not there yet. When it comes down to it, the only real difference is different domain-specific languages and that just results in tribalism.

Autodiscovery is not the norm anymore, though.

Sure. As I said, we're living in post-innovation times and we only develop natively for Linux, Windows, and Mac OS and only on 64-bit Intel.

Except for all the times we don't.

What I meant was that we're moving towards hard dependencies.

Hard dependencies on what? The new BSP release for the next-gen silicon on a new operating system?

Trust me, I was there in the nineties when hard dependencies proved unscalable. The only thing that has really changed since then is the scale (it's gone up orders of magnitude) and the flood of people who have no idea what goes on under the hood.