With the tinderbox now running in a container I’ve been running tests with autoconf 2.64 as well, which is currently masked (and for very good reason I’d say!). This is, after all, the original point of the tinderbox: rebuilding everything with the latest version of the tools, so that if a bug is found users won’t be hitting it before we know about it.
For what concerns autoconf 2.64, I’ve been tracking the issue since last February, when I discovered one interesting change that could have caused a big effect on packages (changed the way they compiled; thus introduced runtime bugs). I also wrote some notes for users and described the incompatible change so that everybody would get ready to fix the future issues.
Well, new autoconf is now here and the run started, I haven’t evens started looking (again) to the present-but-not-compilable warnings, and I already started filing apocalyptic bugs. Indeed, a few packages stopped working with autoconf 2.64, as usual, but there is one that is particularly interesting.
You might remember that I criticised KDE for not using autotools, but rather a crappy buildsystem vaguely based on autotools. Well it seems like my point was proven again, not for the first time I have to say. Indeed the admin/ directory from 3.5.10 fails with autoconf 2.64 and why is that? Because they used internal macros!
Way to go KDE buildsystem developers: autotools are shit anyway, why bothering to stick to the stuff that is actually documented?
*Okay this might just be seen as a sterile comment at something that happened already; on the other hand I’d like to use this to point out that all the FUD about autotools that is available around is often due to what KDE decided, and people should know that KDE didn’t use autotools properly in the first place!*
Also, take this as a warning against autoconf 2.64 unless you really want to start debugging and fixing the bugs.
A note: the way to work around this is just to add a dummy fourth parameter to AC_CHECK_HEADERS that is just