autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal to fork the build-tools projects


From: Soren A
Subject: Re: proposal to fork the build-tools projects
Date: Wed, 16 Oct 2002 22:00:58 +0000 (UTC)
User-agent: Xnews/L5

Peter Eisentraut <address@hidden> wrote around 15 Oct 2002 
news:address@hidden:

> Bruce Korb writes:
> 
>> My console program contains 750K of configure scripts and
>> takes as long to configure as to build.  Ick.  I think it
>> stupid to spend so much energy supporting hobbyist platforms
> 
> And are you implying that this excessive configure run time is because
> of excessive attempts at portability?  What data do you have to
> support that claim?

I think it's just self-evident. I learned how to write bash scripts
before I encountered Autoconf (and after I learned a lot about writing
reasonably good Perl, which is my first programming language). Then I
started learning Autoconf and one of the first things I realized I had
to do was "forget everything I knew" about writing bash scripts.

Now i realize that i seem to be talking about somthing completely
different -- how long it take to *write* something as opposed to how
long it takes to *run* -- but there are numerous impressions i have had
over the years that tell me that 'configure' takes the route of going
very, very slowly over the ground to be covered. I believe there's a lot
of redundancy, a lot of cycle-consuming bloat in Autoconf-generated
shell code (in 'configure'). The use of the cache mechanism only partly
offsets the plodding, circuitous way in which 'configure' arrives at its
destination. 

My common sense tells me that "more symbols == longer run time". Autoconf-
generated 'configure' creates many extra symbols in the quest to address 
portability issues -- like a symbol (variable) containing an "ultra 
portable way to say 'echo -n'" ("$ECHO_N"). Sheesh. Or here's another 
concrete example:


 # Maximum number of lines to put in a shell here document.
 # This variable seems obsolete.  It should probably be removed, and
 # only ac_max_sed_lines should be used.
 : ${ac_max_here_lines=38}

'configure' is full of that sort of stuff.

Yeah, I think it's pretty self-evident. Anyone with a minimal
Journeyman-level coding expertise who is willing to spend a mere
half-hour or so looking over the shell code in a 'configure' will
quickly arrive at a similar conclusion, I believe. 

   Soren A

-- 
Just say NO to YAHAAPs!
(http://groups.google.com/groups?&selm=
Xns92991EB1F396ngrATT586ID%40204.127.36.1)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]