Die GNU autotools

[Elazar Leibovich]

You gave a very good history lesson about the need and reasons for
autotools.

The thing is, many of the software written now, is not intended to run on
HP-UX framework. I'm not a Unix expert, but maybe modern unices are more
POSIX compliant than in the past.

So I think developers prefer to write a more strictly POSIX compliant
application, and to need a simpler building process and have a single set of
source files, than to use non-portable functions and to be forced to use
autotools.

For example, I'd rather implement hton* myself, then checking for this
function's existence with autotools.

A good example for such a project is http://re2.googlecode.com It uses plain
makefile, supports a few unices, and is fairly complex.

On Mon, Jan 10, 2011 at 3:09 PM, Nadav Har'El <nyh at math.technion.ac.il>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.
>
> 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.
>
> 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.
> 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.
>
> Once you forget why autoconf is important, it's easy to start believing
> that
> all sorts of unrelated tools could somehow replace it. 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).
>
>
> --
> Nadav Har'El                        |       Monday, Jan 10 2011, 5 Shevat
> 5771
> nyh at math.technion.ac.il
> |-----------------------------------------
> Phone +972-523-790466, ICQ 13349191 |A bird in the hand is safer than one
> http://nadav.harel.org.il           |overhead.
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20110110/e178e1e9/attachment.html>