Why Switch a Big Software Project to autoconf?

woggo queries: "I'm a CS grad student working on a large research project (over 1 million lines of code, supported on many platforms). The project has been under development for several years, and the build system is nontrivial for end-users. We'd like to make it easier to build our software, and I'm investigating the feasibility of migrating to GNU autoconf. I need to demonstrate that the benefits of autoconf outweigh the costs of migrating a large system of makefiles with a lot of ad-hoc kludge-enabling logic. Has anyone made a similar case to their advisor/manager? Does anyone have some good 'autoconfiscation' war stories to share? (I've already seen the Berkeley amd story and the obvious links from a google search....)" Depending on the intricacies of the build process, such a conversion might take an awful lot of work. It might be easier to put a nicer face on the "nontrivial build process", although there is something to be said for the ease of "./configure; make; make install"

Comments

Even more

[Russ Nelson]

There's even more to be said for running short test programs which discern the same things that configure does, and then writing the correct .h file to disk. That way, you can write a makefile which ALWAYS works. The trouble that I have with configure is that it creates a makefile which differs from machine to machine, so that debugging it is quite difficult. Plus, if configure gets something wrong, you can make and make and make all day long, and you'll never fix it. So even though configure, in theory, saves you from having to maintain a makefile, in reality it means that everyone who runs configure may have to debug the makefile.

In other words, it's better to have one makefile, and fix the problems in the makefile, than to have to fix problems in configure or your configure specification.

If you want an example of how this can work, look at Dan Bernstein's djbdns, or qmail. On both of these, "make" Just Works(tm).
-russ

About to do the same

[4of12]

We have a monstrously large software project with home grown kludges for building on multiple platforms that is a mess of shell scripts and makesfiles. It's ugly and the time required to keep fixing and extending this system is a heavy burden. Plus, it's only tolerable to use.

I've used autoconf a little on a different smaller project and I know this much about it.

When autoconf works, it works great. As a user, there's great delight in typing those 3 magic commands and having a whole series of feature tests fire off and configure the build process. And, as a developer, every time the system works (and it works more than kludge systems), it saves me from hassles of porting to platform de jour. If you look at some fairly complicated systems such as Octave or teTeX build, it's nothing short of amazing.

However, that said, autoconf is complicated. And, you really have no choice but to learn a fair amount of the complications to deal with the issues that will inevitably come up during cross platform testing. I've mostly learned autoconf, a little of automake and almost none of libtool. The m4 macro language for defining the autoconf macros has syntax that always gives me nausea.

If you implement autoconf for your project, great. But, expect a substantial fraction of your time-savings from it to be dedicated to becoming more of an expert at autoconf, m4, sh, etc.

autoconf is better than imake, IMHO, but it sure is short of being as good as it should be. Large projects can justify the time for a person learning the intracacies of autoconf; small projects cannot, unless you happen to know it already. Learning autoconf is kind of like learning nroff just to write a man page - the time investment is more justifiable if you use your expertise to write more than one of them, or to write a really important man page.

P.S. Is there any chance that the software carpentry project will come out with something soon? Some of their early submissions for improved build tools really sounded intriguing, like Tan, an XML based description.