[lmi] autotools versus makefiles

[Greg Chicares]

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
  #endif

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
  #else
                panic(_("`e' command not supported"));
  #endif

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

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

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
  expm1()
  log1p()
  snprintf()
  strtold()
are used even though some runtime libraries don't support them
yet, and we have conditional blocks like

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

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
missing?