automake
[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: Mon, 14 Oct 2002 17:57:25 +0000 (UTC)
User-agent: Xnews/5.04.25

Glenn McGrath <address@hidden> wrote in
news:address@hidden: 

> Pavel Roskin <address@hidden> wrote:
>> If you are going to make a fork, add a well-behaving shell to the 
>> requirements and leave out everything else.  I know a project with 
>> configure script longer than 500k.  Uncompressed sources of ash with 
>> function support are smaller than that.


> Busybox can almost parse configure scripts (sed needs work), its
> designed to be very compact.

I wonder how many times 'sed' is going to need to be rewritten. It seems 
like it must've been rewritten already dozens of times (and still isn't 
very usable IMHO). Oh well, what do I know.

> (im not an expert on autotools and this may sound simplistic, but
> FWIW) Ive often wondered why ./configure has to be a script, i
> understand it has to be portable, but couldnt the build tools compile
> a binary that calls on a c library that provides most of the
> functionality. 

Maybe I am the one now who is totally not getting it, but:

How could you distribute a binary to run on all the different kinds of
systems? I use Cygwin and MinGW. Am I going to be excluded from Open
Source packages because the package maintainer decided not to provide
such a binary? I don't follow the logic here. Are you saying that the
package maintainer will compile a binary "./configure" using h[er|is]
"build tools"? Or are you saying each end user will first unroll the
tarball and then build a binary "./configure" (the latter being the only
way that seems to make sense). Then you still have the problem of the C
library. I assume if the latter, that there will be a canonical download
location (+ mirrors) for precompiled libraries (on my platform(s), that
means Windoze DLLs)? 

I think the idea has potential merit but am not sure i understood
correctly what was being proposed. 

If this could come to pass it would surely be a boon to users like me.
"./configure" typically, on Cygwin for instance, takes me FAR longer
than the entire compilation / linking of more than 60% of the packages i
build. It does seem like the insistence on making the Bourne-ish shell
the lowest common denominator is TOO low (from the present-day
perspective). This may have seemed workable 15 years ago but sure is
wearing badly now.  

   Never lacking abundant opinions,
      Soren A

-- 
What do Internet Mailing Lists and crowded neighborhoods have in
common? Both will either drive you out or teach you how to ignore
barking dogs.






reply via email to

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