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 <[email protected]>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 > [email protected] > |----------------------------------------- > 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 > [email protected] > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il >
_______________________________________________ Linux-il mailing list [email protected] http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
