Re: proposal to fork the build-tools projects

[Soren A]

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

> 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!
(http://groups.google.com/groups?&selm=
Xns92991EB1F396ngrATT586ID%40204.127.36.1)