Although I’ve written about a possible cataclysm related to autoconf-2.64 to warn about the next release, it’s easy for users not to understand why the fuss about it. Especially, Gentoo users have came to know that changes, especially in autotools, tend to be quite disruptive and might actually start asking themselves why people go through that at all, considering that each time a new autoconf, automake, libtool or whatever is released we have to go round and round to fix the issues.
For this reason, I’ve decided to put the upcoming changes in the prospective of users, to let them understand that all the work that is going on for this is going to be quite useful to them, on the longish run. I say longish because the change I’ve blogged about, the handling of present-but-not-compilable headers, is something that was in the making since at least 2.59, which was out already when I joined Gentoo the first time, just to give a timeframe, this was about three years ago if not more (a quick check on the ChangeLog file dates the start of the transition to 2001-08-17, that’s almost eight years ago!).
The change was done with quite a good technical reason: just checking if an header if present is of no help, even though it’s not just a stat() call like CMake does, but it does go through the preprocessor (which in turn makes it possible to consider an header that is found but not usable as not present, like malloc.h on Mac OS X), the developers most likely want to know if the header can be used in their project. Which means it has to work with the compiler they are using, and with the options they are enabling.
Since changing the behaviour between one version and the other wouldn’t have given enough time to people to actually convert their code to check properly for header usability, for a while autoconf-generated configure files checked both that the header was present (through the preprocessor) and that it was usable (through the compiler). This, though, creates long, boring and slow configure files because it checks for more stuff than needed: for each header file in a AC_CHECK_HEADERS macro, there are two process spawned: preprocessor and compiler. As you might guess, this gets tremendously boring on projects that check just shy of an hundred header files.
While the 2.64 version still checks for both preprocessor and compiler, and warns in the case the compiler rejects an header that the preprocessor accepted and vice-versa (the compiler always winning now), hopefully we won’t have to wait till 2017 to have just one test per header in the configure output, which will finally mean shorter, slimmer, faster configure scripts.
Another interesting change in the 2.64 release which makes it particularly sweet to autotools fanatics like me is the change in AC_DEFUN_ONCE semantics that makes possible for macros to be defined that are executed exactly once. The usefulness of this is that often times you get people to write bad autoconf code, that instead of using AC_REQUIRE to make sure a particular macro has been expanded (which is usually the case for macros using $host and thus needing AC_CANONICAL_HOST), simply call it, which would mean the same check is repeated over and over (with obvious waste of time and increase in size of the generated configure file).
Thanks to the AC_DEFUN_ONCE macro, not only it’s possible to finally define macros that never gets executed more than once, but also most of the default macros that are supposed to work that way, like AC_CANONICAL_HOST and its siblings, are now defined with that, which means that hopefully even untouched configure files will be slimmed down.
Of course, this also means there are more catches with it, so I’ll have to write about them in the future. Sigh I wish I could find more time to write on the blog since there are so many important things I have to write about, but I have not enough time to expand them to a proper size since I’m currently working all day long.
