I mostly agree with the list, but i think there are also some arguments what are suboptimal about Autoconf:
1) We do not need to support old buggy platforms, we can generally assume that platforms are open source and their bugs can be fixed, so it is less pressure to workaround them in application software. Consequently, we do not need that detailed checks
2) We can assume there is fully working POSIX shell, so configure script and its checks could be made just in shell, no need to have M4-generated shell code.
3) It is probably better not have separate 'release-phase', so end-users could just work with code from git. Users could run Autoconf themselves to generate the configure script, but the Autoconf is not well-suited for this, as there is lack of backwards compatibility.
4) Most developers do not know M4, so they just hack around Autoconf macros without proper understanding.
5) It would be nice if all these directories that are given to configure scripts could be overridden at runtime using environment variables
Ideally, there could be POSIX shell script library that could be used to write portable configure scripts offering all the standard options and checks like ones generated by Autoconf.
You have to set some baseline. We assume the CPU can divide numbers correctly, even though not all of them did.
Autoconf has set the baseline so low that everyone perpetually pays for the technical debt of ancient buggy platforms. Sometimes it's better to push a buggy platform to fix its own bugs, than to have everyone work around those bugs forever.
The issue is defining "support". I would argue it can be harmful having autoconf detect a non compliant shell and advertise it was trying to build a makefile around that fact if no one has ever tested your app on such a platform and something in the code will fail anyway.
Everybody uses a POSIX shell today. Unless you're a basement dweller using OpenSolaris or something, and probably even then
Then guess what, I'm not building software for you
From the article:
> Of course, the checks should be reasonable (and in practice, often are excessive). If your code assumes a C99 environment, you don’t need to check whether all C99 functions you use are available.
Which makes sense to me (including the check based approach).
1) We do not need to support old buggy platforms, we can generally assume that platforms are open source and their bugs can be fixed, so it is less pressure to workaround them in application software. Consequently, we do not need that detailed checks
2) We can assume there is fully working POSIX shell, so configure script and its checks could be made just in shell, no need to have M4-generated shell code.
3) It is probably better not have separate 'release-phase', so end-users could just work with code from git. Users could run Autoconf themselves to generate the configure script, but the Autoconf is not well-suited for this, as there is lack of backwards compatibility.
4) Most developers do not know M4, so they just hack around Autoconf macros without proper understanding.
5) It would be nice if all these directories that are given to configure scripts could be overridden at runtime using environment variables
Ideally, there could be POSIX shell script library that could be used to write portable configure scripts offering all the standard options and checks like ones generated by Autoconf.