Andreas Buening <[EMAIL PROTECTED]> wrote around 14 Oct 2002 [EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> 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)
