Putting an user prospective to the upcoming changes in autoconf 2.64

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.

What will I do next

So, quite a bit of people asked me what I’ll be doing now that I left Gentoo.

For sure, I won’t be bored. I have xine to work on (I’ve cleaned up some stuff in the past days already), I’ve Rust to complete, and a few Rust extensions to work on.

I have my job, that will take me more time now anyway because it’s coming to the end of the contract, so I was already planning into going in away from Gentoo for the time needed to complete the job.

I have the SPARC64 problem to debug, now that I put the Intel card in it the network performance is decent and I can probably start looking more into kgdb.

Today I also got something new to work on: not sure if I blogged about this before, but last month I ordered four USB to serial converters from eBay from an Hong Kong shop, they were cheap and I needed quite a bit of them, and I received them today. I hoped they were PL2303 based as they seemed identical to a similar product in an Italian shop, in Photo. Unfortunately, they are not. The chip used is from a Chinese manufacturer WCH, I have some Windows drivers for it, but that’s it. I’ve sent a mail to the company, in hope they can provide me some specs about these, they already got spec of some of their chips on the site, although in Chinese; if they can provide me that, I’ll see to write a driver for these, as, well, I need them, and it seems to be an easy task to start looking at kernel’s internals, and I might buy a few more of these, because serial ports aren’t really that common nowadays, and they are quite needed when working with embedded stuff.

As I said there is a lot of things for me to do, and even if I still have to find anything about building model ships (that is something I’d like to do, I like the results, and it’s something that would take me enough time so that I can relax myself), I’ll probably try to find something to do away from the keyboard just to relax myself.

And maybe, now that stuff seems to have started moving, in two or three months I might consider coming back. Not now for sure, and not too soon, but if the currently problems will be sorted out, I might consider it for the future. In the mean time I’ll still be around anyway, as an user contributing patches when it seems fit.

Update (2017-04-29): Looks like WCH is gone. On the other hand, someone else already contributed a ch314 driver, so I never actually implemented this myself.