I think your criticism is a bit outdated itself :-P, Autotools hasn't been supporting pre-C89 compilers for a long time now. C89 is the minimum requirement, the reason that the pre-C89 code was there was most likely because pretty much all compilers so far accepted K&R style and thus it still worked, so nobody bothered to update it. This code has now been replaced, the bigger issue with that is that there hasn't been a new release with the fixes (some distros do have the patches applied though - but sadly not mine, though i guess i can just download them myself).
Also as i replied to the other comment, you can still regenerate the configure script if you have Autotools installed, however the benefit of Autotools is that you don't have to have Autotools installed to build a project (you can always generate those scripts on another computer).
You're missing the point. "Nobody bothered to update it" is key. It's not being proactively maintained, and as a result it's looking to the past, and ignoring the present. And it's not just about this one specific defect, that's just the example of the moment. And being fixed but not released is just the icing on the cake. These tools are no longer being actively and properly maintained.
I'm really asking about the bigger picture about the whole philosophy of what problems the Autotools are trying to solve, and why. Yes, the Autotools are ostensibly for "portability", but if you dig a bit deeper you start to appreciate firstly how outdated it is in terms of the specific portability problems it tackles, with many current portability problems being completely unaddressed, and how superficial a lot of its solutions are. At one time, the Autotools were the showcase for how to solve portability problems, but this is no longer the case.
Regarding regeneration of the scripts. Of course you can. But embedding is superficially helpful but ignores the bigger-picture issue of having outdated junk in thousands of projects' release artefacts. No other build system actively recommends embedding themselves in source releases. And we all use them without trouble. If anything, embedding generated files also exacerbated the (historically) poor compatibility story of Autoconf and Automake, back when it was being actively developed. Embedding hid this to some extent, though developers often had to have several versions of each installed. The only reason this stopped being such a problem is because the maintenance of both effectively ceased. (Yes, I know they are still nominally maintained, but they are in end-of-life maintenance at this point.)
> You're missing the point. "Nobody bothered to update it" is key. It's not being proactively maintained, and as a result it's looking to the past, and ignoring the present.
Nobody bothered to updated not because of maintenance but because it wasn't broken. The moment it was pointed out that this is an issue the developers fixed it - this was already fixed in the repository last year.
> I'm really asking about the bigger picture about the whole philosophy of what problems the Autotools are trying to solve, and why.
Autotools, or at least Autoconf, are trying to solve the problem of figuring out at build time if something is available while minimizing the dependencies the user (builder) has to provide to what is assumed to be there.
> Yes, the Autotools are ostensibly for "portability", but if you dig a bit deeper you start to appreciate firstly how outdated it is in terms of the specific portability problems it tackles
Sorry but this "outdated" aspect is not specific, ask different people and they'll come up with different answers of what is outdated. The only thing that matters is if it works and so far it seems to work.
I'm not going to defend how Autotools/Autoconf work or are implemented, because they are a mess, but i do defend both the idea of minimizing dependencies for the users and the test-based approach they are using.
> embedding is superficially helpful but ignores the bigger-picture issue of having outdated junk in thousands of projects' release artefacts.
As i wrote, the question is a matter of if they work or not. If they work, then that is perfectly fine, they do what they are supposed to. If they do not, they can be regenerated using Autotools, which brings it back to almost the same position as other build systems that need themselves available to work.
And i write "almost" because Autotools are still better here: chances are they'll still work and if you need to regenerate the scripts you can do it in another machine that has the dependencies already available.
> No other build system actively recommends embedding themselves in source releases. [..] And we all use them without trouble.
Sorry but this comes in complete contrast with my experience actually building software with Autotools, especially on platforms that aren't your standard desktop Linux setup and do not have everything and the kitchen sink there. Projects using autotools just work there and provide the best UX of all other systems.
Hell, i mentioned i recently decided to use Autotools for some of my own projects - i didn't because they were nice or easy to use (though they weren't particularly hard either). If anything as a developer i find something like premake much easier and convenient but i also care about the user's experience and Autotools not only do much better there but also give a bigger bang (features) for buck (effort from my side and dependencies for the user).
Also Autotools do not embed themselves in the source releases, they generate script files to generate the makefiles. Autotools have dependencies for themselves that are not required to build the software releases (unless you want to regenerate the scripts).
Also as i replied to the other comment, you can still regenerate the configure script if you have Autotools installed, however the benefit of Autotools is that you don't have to have Autotools installed to build a project (you can always generate those scripts on another computer).