[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] autotools versus makefiles

From: Greg Chicares
Subject: [lmi] autotools versus makefiles
Date: Fri, 13 Jan 2006 11:15:46 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

We've been discussing the merits of two different build systems
off the mailing list from time to time. It seems like a good idea
to continue the discussion here. Two build systems is one too
many, and, in retrospect, forking this seems like a mistake.

Here's what I still don't understand: what's the advantage of
autotools for lmi? Let me try to explain the advantages that I do
understand, taking 'sed' as an example because it's fairly small
and I've built it with autotools. In the 'sed' sources I see:

  #ifndef HAVE_STRCHR
  # define strchr index
  # define strrchr rindex

If you don't have strrchr(), try to use rindex() instead. The 1989
C standard requires strrchr(). This is helpful if your C standard
library lacks that required function but supplies rindex().

And here's the nifty thing about autotools: the 'configure' script
automatically determines whether or not strrchr() is supported,
and defines macros like HAVE_STRCHR accordingly. Thus, once the
conditional block above is written, the code adapts to systems
that have rindex() but not strrchr(); presumably there were quite
a few systems like that when GNU 'sed' was written in 1989. On
systems that have neither, it fails.

Similarly, code like this

  #ifdef HAVE_POPEN
                panic(_("`e' command not supported"));

lets the program build even if a presumably-optional feature is
missing. And this block

  #ifdef HAVE_STDLIB_H
  # include <stdlib.h>
  #ifndef EXIT_FAILURE
  # define EXIT_FAILURE 1

lets you use a standard macro even if the C89 header that defines
it is lacking.

The HAVE_* macros are written by autoconf, but the code that uses
them still has to be written by a programmer.

If the 'sed' maintainers decided to require a C compiler that
conforms to the 1989 standard (at least), then they could replace
the last block of code with
  #include <stdlib.h>
because the standard requires that header. They won't do that, of
course: why remove support for nonstandard systems when it has
stood the test of time and harms nothing?

There's some similar code in lmi: these four C99 functions
are used even though some runtime libraries don't support them
yet, and we have conditional blocks like

  // COMPILER !! This workaround is rather poor, of course.
  inline long double strtold(char const* nptr, char** endptr)
  {return strtod(nptr, endptr);}

but we have far fewer such blocks than, say, 'sed' does. Macros
like LMI_COMPILER_PROVIDES_STRTOLD come from a compiler-specific
'config_*.hpp' file that's written by hand.

Here's a real advantage of autoconf: it could write those macros
for us. The offsetting disadvantage is that it's one more tool to
learn and maintain.

I don't see a compelling case for adopting autotools. What am I

reply via email to

[Prev in Thread] Current Thread [Next in Thread]