Die GNU autotools

[Nadav Har'El]

On Tue, Jan 11, 2011, Elazar Leibovich wrote about "Re: Die GNU autotools":
> On Tue, Jan 11, 2011 at 7:09 AM, Shachar Shemesh <shachar at shemesh.biz>wrote:
> I really don't think the dependencies and sizes really matters for the
> problem I've had, but instead of arguing about it I see your VLC and I raise
> you by the go programming language.
> 
> The go programming language is a fairly complex beast, is cross compiled to
> ARM architecture, support gcc front ends, and does not need any of the
> autotools. http://golang.org/doc/install.html

I couldn't agree less.

I'm a big fan of Google, Rob Pike (who wrote the book from which I learned
Unix 26 years ago) and Ken Thompson (who wrote that Unix ;-)),  so when Go,
written by Thompson and Pike at Google, came out, I just *HAD* to try it.

So I downloaded it, and tried to compile it, on my a fairly "normal" Linux
desktop, and after about an hour of trying just gave up (and went to read
the language documentation instead). Instead of a simple "configure" script
which figures out what needs to be figured out, apparently to compile Go
you need to set up a special directory structure, and set up all sorts of
environment variables, and only then you can compile.

Why would anybody think that this is simpler than "configure; make"?

Would Go also compile Solaris? On AIX? On True64 UNIX (if you happen
to have an Alpha machine)? On various versions of Fedora/Debian/Ubuntu/Gentoo
from the last 10 years? You can say you don't care, but I do. Even if
(sadly) nowadays it seems that everyone is using one computer architecture
and one operating system (Linux. I'm not even considering MS-Windows ;-)).

> You can probably find small details that don't work exactly as they could
> with the autosuite, but this software is working and compiling really easily
> with less maintenance hassle for 99.9% of its users. This is a living
> testimony that projects can have a good build system and be fairly portable
> even without the autosuite, and you must agree with me that the autosuite
> isn't exactly straightforward, and makes simple things more complex:

I'm afraid I don't understand - when is the autosuite a hassle for the
end-users (the people who compile the software)? I can understand (even if
not agree) about complaints of the software developers, but what do users
have to complain? They just run "configure; make".

> Using autotools for a very simple piece of software still requires a few
> > steps:
> >
> >    1. Move the Makefile to Makefile.in
> >    2. Run autoscan
> >    3. Edit the configure.in file
> >    4. Run autoconf
> >    5. Test ./configure
> >    6. make any final adjustments
> >
> > If this is simple, I don't want to know what complicated is.

The first project in which I used autoconf on was HOC (see
http://nadav.harel.org.il/homepage/hoc/), back in 1997. It took me a few days
to read the entire autoconf documentation (I had a lot of free time on the
bus to work...), and a couple of days to get (mostly) everything right in
configure.in and Makefile.in after the initial run of "autoscan".

You can argue that this is complicated - that spending a few days on such
build details it way too much. But I disagree. At that point, I'd been
developing this software for almost a decade, and had run it on more than
a dozen different variants of Unix, and many versions thereof, and I've
accumulated a big ugly Makefile and a big ugly INSTALL instructions, which
you needed to follow to compile it. Were you using ANSI C? Set this flag.
Were you compiling on AIX? Set that flag. Do you have matherr(3)? gamma(3)?
Did your C compiler had a specific bug that was only found on one specific
machine? Were you using Bison or AT&T yacc? At some point, I even created
a Metaconfig-style script which asked you questions and set the appropriate
flags for you. A typical example question was this:

   Question 2: are you now compiling  hoc on an AT&T Unix-pc  (or otherwise
               known as  a 3b1 or 7300)? if yes, hoc will not use certain C
               constructs which are known to cause bugs on Unix-pc's.

(see http://en.wikipedia.org/wiki/3B1 if you don't know what this means ;-))

So I spent a few days on a "configure" script, but my users (including myself)
no longer had to follow complicated installation instructions and answer
obscure questions any more. 

I think it was well worth it.

> Compare that
> to godag http://code.google.com/p/godag/wiki/Compiling or ANT[1], the
> initial script which just compiles everything and keeps dependencies is
> extremely simple.

I've also used ANT extensively, and I'm not impressed.

ANT is very limited to things it knows how to do, and mostly specific to
Java (and Java-related tools), and assumes that portability is guaranteed
by the language, so you don't need to test anything. I've never seen a Java
project which could work on different versions of Java because of a clever
ANT script. This is the bread and butter of autoconf - to get the same code
to run on dozens of types of systems, be they different Linux distributions,
different Unix versions, or even just different compilers written over the
period of 10 years.

> Maybe in the old days the autotools was mandatory because, you could not
> afford checking things at runtime or compiling things you don't 100% need
> into the executable (thus using config.h to ifdef pieces of code out).
> But nowadays this is wrong both from practical POV (you can afford those
> extra bytes in order to make building the software more straightforward),
> and both from philosophical POV, I want the source code to be the same in
> all platforms if possible, and defer the checks I have to make to runtime,
> this makes things easier (a user has a bug - did you compile your software
> with --can-haz-cheeseburget?), autosuite encourage me to go to this
> direction.

I'm afraid I don't understand what you mean.

To use you Java & ANT example, let's say that you wrote a Java program in
Java 1.3, in the year 2000. In 2002, came Java 1.4, and had some useful new
features. How would ANT or those "runtime checks" help you run code that
could compile on both Java 1.3 and Java 1.4, and in 2005 on Java 5?
Some things you could do with reflection, but not everything. The fact that
Java does not have anything analogous to a C preprocessor, and ANT has nothing
analogous to configure's compiler test, meant that you usually had to choose
one very specific Java version, and force your users to compile with that
version.

Just as an example, consider the Apache Lucene project, a very useful Java
search-engine library. Would you believe that until the end of 2009, Lucene
had officially stuck to Java 1.4 and could not use any new Java 5 features,
even conditionally? Remember that Java 5 had come out 5 years earlier...

Now imagine that instead of having just 3 Java versions in those 5 years,
you would have had to deal with 30 different versions from 10 different
compiler makers and 10 different library makers... The fact you don't have
30 different versions just says something about (formerly) Sun's stranglehold
over Java's, it doesn't say anything good (in my opinion) about Java or ANT.

> <project>
>     <target name="compile">
>         <mkdir dir="build/classes"/>
>         <javac srcdir="src" destdir="build/classes"/>
>     </target>
> 
>     <target name="jar">
>         <mkdir dir="build/jar"/>
>         <jar destfile="build/jar/HelloWorld.jar" basedir="build/classes">
>         </jar>
>     </target>
> </project>

Here you are demonstrating that you think ant is better than *make*, not
*autoconf*.

Make is older than autoconf (Stu Feldman wrote it in 1977), and while it
had some great new ideas at the time, I tend to agree that it should be
replaced by something better, with more features and less archane syntax
(like that odd first-character-must-be-tab rule), but I certainly don't
think that ANT, with its horrendous XML-based syntax is it.


-- 
Nadav Har'El                        |      Tuesday, Jan 11 2011, 7 Shevat 5771
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Everybody lies, but it doesn't matter
http://nadav.harel.org.il           |since nobody listens.