[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)
- Re: proposal to fork the build-tools projects, (continued)
Re: proposal to fork the build-tools projects, Pavel Roskin, 2002/10/13
Re: proposal to fork the build-tools projects, Soren A, 2002/10/14
Re: proposal to fork the build-tools projects, Dean Povey, 2002/10/14
Re: proposal to fork the build-tools projects, Glenn McGrath, 2002/10/14
Re: proposal to fork the build-tools projects, Bruce Korb, 2002/10/14
Re: proposal to fork the build-tools projects, Andreas Buening, 2002/10/14
Re: proposal to fork the build-tools projects, Soren A, 2002/10/15
Re: proposal to fork the build-tools projects, Bernd Jendrissek, 2002/10/15
Re: proposal to fork the build-tools projects, Soren A, 2002/10/14