[Top][All Lists]

[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: Tue, 15 Oct 2002 07:46:33 +0000 (UTC)
User-agent: Xnews/L5

Andreas Buening <address@hidden> wrote around 14 Oct 2002 

> Even more, to my knowledge for systems like Cygwin, MinGW and EMX
> the configure time depends only on the number of fork() calls.
> I guess, it doesn't matter whether you have a shell script or a binary.
> If both have the same number of fork() calls they need the same time
> to run.

That might be, Andreas. Others have a lot more knowledge about what
makes things slow, than i do. I *can* tell anyone that typically MinGW
procedures run at least 100% faster (as a subjective estimate) than
Cygwin ones. (Neveretheless let me be clear that I am not downing Cygwin
or b*tching about it).

But I know in a general theoretical sense that starting new processes on 
Windows is expensive, unavoidably and invariably. You are certainly right 
about that.

This would mean that for such a proposed new "./configure" system as we are 
discussing here to be successful on 'doze platforms, it would have to keep 
the number of forks (new spawned sub-processes) to a bare minimum. That 
would require discipline on the part of those that write such a thing with 
their minds primarily focused on its utility as a tool for Linux, to resist 
the urge to use the easy fork() available with wild abandon. Thus we have 
the same problem we are trying to run away from, presently: that writing 
and maintaining the "./configure" setup is extra-laborious because so many 
things need to be borne in mind: other people's platform limitations -- not 
just our own preferred platform's characteristics.

  Just a few more thoughts...
   Soren A

Just say NO to YAHAAPs!

reply via email to

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