The GNU Configure and Build System consists of autoconf, automake, and libtool. I wrote an essay about them a long time ago. Slightly more recently I was a co-author of a book about them.
David MacKenzie started writing autoconf way back in 1991. I was an early beta-tester and contributed some early features. autoconf generates a configure script written in portable Bourne shell script language. That makes sense. autoconf at the time was essentially an M4 script. That made sense at the time, but no longer does. Today autoconf is essentially a perl script that invokes M4. That doesn’t make sense today either.
automake is a completely separate program. It essentially provides a simplified Makefile language. David MacKenzie started writing it in 1994 as a portable shell script plus Makefile fragments. In 1995 Tom Tromey rewrote it in perl. I first used it in 1997, and added support for conditionals. automake works with autoconf. automake translates a Makefile.am file written in the automake language into a Makefile.in file written in the make language. The configure script generated by autoconf then applies substitutions to generate a Makefile from Makefile.in.
libtool is essentially a complicated portable shell script which creates shared libraries. It was written by Gordon Matzigkeit starting in 1996. libtool provides a standard set of commands for compiling and linking to create shared libraries, and for installing them. It does this in a rather baroque manner in which what appears to be library is actually a shell script pointing to the real library, which libtools reads when doing a link to decide just what to do. automake has support for using libtool.
This build system is used by many different tools, including pretty much all GNU tools. However, it has a major problem: it is much too complicated. It is written in portable shell, perl, and m4. It does not work in a intuitive or transparent manner. autoconf input files mix shell and m4 code. automake input files mix the automake and make languages. libtool hides its files in a hidden directory named .lib. The system does work fairly well. But it is hard to understand and hard to debug. And configure scripts generated by autoconf are slow. In a distcc environment, it is not uncommon for it to take longer to run the configure script than it takes to build the program.
We have to get rid of these tools. There have been many alternative build systems. Not of them have caught on, at least not in the free software world, because they have to be installed before they can be used. The great advantage of the GNU system is that it requires nothing more than portable shell and portable make.
However, we can do better today. The GNU make program is very powerful, much more powerful than the original make program. GNU make is installed on every popular development platform. Let’s take advantage of it by assuming that it is there.
The goal would be to have people write a single Makefile. instead of configure.in and Makefile.am or Makefile.in. (We would probably keep a configure script for compatibility, and to record options like –target). The Makefile would start with a standard include directive which provided all the default commands. The rest would just be a standard GNU Makefile with some restrictions, like no %.o: %.c command, and with some standard variables to describe compilation options and the like.
The standard include would ensure that every compilation depended on config.h. config.h could be built by grepping the source code for HAVE_xxx strings and the like. Each string would map to a test which would have an appropriate rule. These rules could be run in parallel to generate tiny header files with the appropriate #define. config.h would include all the tiny header files.
This would provide an interface similra to autoconf/automake, but simpler to use and faster to run. Of course there would be many details to work out. But I think an approach along these lines has real promise to get us out of the current quagmire.
Leave a Reply
You must be logged in to post a comment.