Re: [lmi] autotools versus makefiles

[Vadim Zeitlin]

On Fri, 13 Jan 2006 11:15:46 +0000 Greg Chicares <address@hidden> wrote:

GC> but we have far fewer such blocks than, say, 'sed' does. Macros
GC> like LMI_COMPILER_PROVIDES_STRTOLD come from a compiler-specific
GC> 'config_*.hpp' file that's written by hand.
GC> 
GC> Here's a real advantage of autoconf: it could write those macros
GC> for us. The offsetting disadvantage is that it's one more tool to
GC> learn and maintain.
GC> 
GC> I don't see a compelling case for adopting autotools. What am I
GC> missing?

 I don't think you miss anything, you've summarized the main advantage of
autoconf in an excellent way. It just allows you to write a test for
whatever function you want to use once instead of writing config.hpp
manually for each supported compiler. Of course, the gain is especially
noticeable when you use many compilers: autoconf is clearly overkill if you
only use one system and one compiler. LMI is in somewhat middle ground: it
is currently built under Windows and Unix but using one compiler only. So
the advantage of autoconf right now is debatable. But I do believe that if
we plan to support more compilers, it can become quite important.


 A few other things:

- tests for functions can be written manually, but configure may also do
  other compile-time checks, e.g. verify whether the correct version of
  wxWidgets is available (and built with correct options), whether we have
  boost installed (or need to build it as part of lmi) and so on -- this is
  very nice IMO and is impossible without using a separate tool and so the
  only way to do it is by manually specifying the build parameters and, of
  course, "manually" means more space for mistakes

- autoconf makes integration with other tools usually easier because it is
  a well-known standard; e.g. creating Debian (or cygwin, for that matter)
  packages is much simpler if you have an autoconf-based build system

- we gain a few very nice features for free when using autotools:
   . standard configure arguments such as --prefix or --enable-debug:
     it's really convenient to be able to specify them in a usual way
     instead of having to modify the makefiles or pass the flags on
     command line

   . possibility to build in another directory: this is much more tidy than
     building in the source directory

   . make targets such as install, dist, ... are implemented automatically
     (this is done by automake and not autoconf but it doesn't matter)

   . without speaking of automatic dependency tracking (and hopefully in
     the future automatic precompiled headers support)


 Speaking of automake, I do believe that Makefile.am is much more simple
(and hence maintenable) than its equivalent(s) in the manual build system.
Of course, it probably doesn't do everything it does but still.


 Finally, let's put it the other way: what are the advantages of not using
autotools? We already have a working (barring last minute breakage since
our last tests) autotools-based system. It works under Linux, Cygwin and
MSYS and normally should require much less maintenance than the original
makefiles in the future. So what prevents you from using it?

 Thanks,
VZ