I don't intend to engage in yet another 9fans flame war. I do not argue with your analysis or proposal. However, it's based on considerable hindsight and experience that wasn't available when autotools started. Additionally, systems in that time period were changing continually. So it was not always true that what any given system provides is known in advance.
The autotools (and especially gnulib) are bloated. A better design is possible. But it's unfair to say that at the time they could have done a lot better; I don't think that's true. "Hindsight is always 20/20". That's all I'll say on the topic. Arnold tlaro...@polynum.com wrote: > On Thu, Jul 09, 2015 at 09:24:57AM -0600, arn...@skeeve.com wrote: > > So, the history is more than this. > > > > Larry Wall's Configure (capital C) for rn and Perl was the first step > > at a shell script to examine system features and generate a config.h. > > Using a shell script to generate commands to compile on diverging Unices > was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this > predates Perl and so on. I guess it is not the only example. > > >[...] > > Autoconf was designed to solve real portability problems. > > There are two problems with the autotools stuff: > > 1) Features are fixed for OSes, but the configuring is done other and > other again for every program. What a system offers shall be known; and > what the developers require shall be known too. Autotools was designed > in a world where neither the OS nor the developers exactly know what > they use; > > 2) Cross-compilation was not in mind, with some features tested by > compiling and running programs. The result is that the majority of > software built with autotools needs to be compiled natively (even > installed on an equal system since the layout is searched on the > building node); > > 3) To try to understand what's going on with several steps and huge > configs is out of reach. > > Rule: when it takes less time to build a solution from scratch than to > try to understand how to _use_ an existing solution (not to mention > understand), this solution has to be safely stored in /dev/null. > > Note: I have put my money where my mouth is : I have built such a > solution: the one publicly used with kerTeX---but it is a side > effect, it was not meant to be released. And it solves the 1) and > 2) and solves too the space problem: when an object is not any > longer necessary, it can be automatically removed, limiting the > space needed to compile to the bare minimum. > > -- > Thierry Laronde <tlaronde +AT+ polynum +dot+ com> > http://www.kergis.com/ > http://www.arts-po.fr/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
