Die GNU autotools

[Shlomi Fish]

On Monday 10 Jan 2011 15:09:03 Nadav Har'El wrote:
> On Mon, Jan 10, 2011, Shlomi Fish wrote about "Re: Die GNU autotools":
> > On Monday 10 Jan 2011 12:49:25 Ilya A. Volynets-Evenbakh wrote:
> > > My feelings too. A while ago I got so tired of autotools that I even
> > > started working on my own build system intended as a semi-drop-in
> > > replacement. It's purely make-based. If interested, take a look at
> > > the sources http://sources.total-knowledge.com/gitweb/?p=adon-banai.git
> > 
> > Well, after a small experimentation with SCons ( http://www.scons.org/ )
> > which I didn't really like (but is still better than GNU Autohell), I've
> > finally settled on CMake - http://www.cmake.org/ - which is awesome in
> > almost every
> 
> It saddens me that people bundle Autoconf and Automake under one name
> "autotools", because it causes people to miss that Autoconf *is* the best
> thing since sliced bread, while the rest of them are, well, not.
> 

Not true - see below.

> To appreciate just how great autoconf is, you have to remember what
> transpired before it was invented in 1991.
> 
> In the 80s, if you had a C program which was to run on the many variants of
> Unix that existed then, you'd normally write a complex Makefile with all
> sorts of parameters, and before a user could compile your program, he would
> need to edit this Makefile, and turn on or off various flags, fill in
> locations of various programs, and so on. This was extremely annoying so
> two solutions were invented: Larry Wall (of Perl fame) invented
> "Metaconfig" which would *ask* the user questions instead of asking him to
> edit a Makefile - this was somewhat easier, but equally annoying and
> time-consuming. The X-Windows people invented "imake", where the user
> would basically answer all possible questions once (and put them in a
> system-global config file), and when the user runs "xmkmf" a Makefile is
> created from an "IMakefile" using these defaults. Imake was also not a
> silver bullet, because it made it impossible for new projects to ask new
> questions beyond the "usual" ones that were already answered when X11 was
> installed.
> 
> Then (1991) came autoconf, and solved all these problems. It wouldn't ask
> you silly questions that it could figure out automatically (if some library
> is available, were is some binary, is some feature of the C compiler
> available, etc.), and every program could define the specific questions it
> needed answered, using basic building blocks that autoconf made available.
> Autoconf was so good, and so much better than anything that was available
> before, that pretty soon *every* free software came with a "configure"
> script.

Well, I still recall some programs that did not switch to Autoconf (and some 
had a configure script).

> 
> Fast forward 20 years, and autoconf is just as good as it used to be, but
> most people are starting to forget why it was needed, and only remember its
> quirkiness, like the fact it uses the bizarre "m4" as its base.

And that it has problems with backwards compatibility and forward 
compatibility, and that its configuration and building are slow, and many 
other problems as far as the developers (and sometimes end users are 
concerned).

> One reason why people forget how good autoconf is, is that they hardly see
> different variants of Unix, and the differences between Linux distributions
> are typically smaller. Another reason for forgetting autoconf's greatness
> is that "normal" people don't compile any more! Most Linux users get
> precompiled binaries from their distributions, and it is the
> distribution's packagers which do the compilation. Finally, these
> packagers (who do the compilation) don't really care if the source code
> used autoconf, or a hand-tweaked Makefile, because they anyway *patch* the
> source code with all sort of distribution- specific modifications, so they
> could care less about *patching* the Makefile. This state of affairs is,
> in my opinion, sad.

Well, having something with a portable and configurable build system generally 
involves less patching and custom modifications and so is more desirable as 
far as packagers (or end-users who build the packages from source) are 
concerned.

> 
> Once you forget why autoconf is important, it's easy to start believing
> that all sorts of unrelated tools could somehow replace it. 

CMake is certainly not unrelated.


> Things like
> Cmake and Adon-Banai can hardly be considered replacements to Autoconf -
> perhaps they are better "make", perhaps they are "imake done again", but
> not "better than autoconf".
> (note: since I never actually used Cmake or Adon-Banai, I may be missing
> something, so feel free to correct me).

CMake is "better than autoconf" since it does anything Autoconf does, only 
better. It allows you to get answers to questions about the system and how the 
user wishes to build the program, including by reusing macros and modules from 
the core CMake distribution or from third parties. I've summarised the 
advantages of CMake over Autoconf here:

http://www.shlomifish.org/open-source/anti/autohell/

As an example, here's a portion from Freecell Solver's CMakeLists.txt file 
that checks for the existence of Google's tcmalloc:

{{{{
SET(LIBTCMALLOC_LIB_LIST)

IF (NOT CMAKE_BUILD_TYPE STREQUAL debug)

    IF (NOT FCS_AVOID_TCMALLOC)
        # Optionally link against Google's TCMalloc if it's available:
        # http://goog-perftools.sourceforge.net/
        # This gives better performance for the threaded programs.
        FIND_LIBRARY(LIBTCMALLOC_LIB tcmalloc)

        IF(LIBTCMALLOC_LIB STREQUAL "LIBTCMALLOC_LIB-NOTFOUND")
            # Do nothing.
        ELSE(LIBTCMALLOC_LIB STREQUAL "LIBTCMALLOC_LIB-NOTFOUND")
            # Cancelling for now to see if it helps with the valgrind problem.
            # TODO : restore
            SET(LIBTCMALLOC_LIB_LIST ${LIBTCMALLOC_LIB})
        ENDIF(LIBTCMALLOC_LIB STREQUAL "LIBTCMALLOC_LIB-NOTFOUND")
    ENDIF (NOT FCS_AVOID_TCMALLOC)

ENDIF (NOT CMAKE_BUILD_TYPE STREQUAL debug)
}}}}

FIND_LIBRARY has an equivalent in Autotools-land, and CMake can do all that. I 
don't know about "Adon-Banai" because I never used it but CMake can perform 
the functionality of Autoconf that you describe.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Funny Anti-Terrorism Story - http://shlom.in/enemy

Chuck Norris can make the statement "This statement is false" a true one.

Please reply to list if it's a mailing list post - http://shlom.in/reply .