Re: GIT on MinGW problem

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Sun, 27 May 2007, Han-Wen Nienhuys wrote:

> Jakub Narebski escreveu:
> > On Sun, 27 May 2007, Steven Grimm wrote:
> >> Han-Wen Nienhuys wrote:
> >>> Shawn O. Pearce escreveu:
> >>>> On systems like Cygwin the fork+exec overheads are very high
> >>> A well written configure script is able to detect presence
> >>> of a linkable libcurl.
> >> IMO the reasons configure is so unwieldy, at least as it's set up in 
> >> most open source projects, are that a) it spends 95% of its time 
> >> checking for things that basically never vary (yes, I have stdlib.h, 
> >> thank you) and that b) it doesn't remember the results from previous 
> >> runs on the same host (I'm just changing the install path; my ints won't 
> >> have stopped being 32 bits as a result.)
> > 
> > ./configure _can_ cache tests results:
> > 
> > $ ./configure --help
> > [...]
> >       --cache-file=FILE   cache test results in FILE [disabled]
> >   -C, --config-cache      alias for `--cache-file=config.cache'
> > 
> > but it does not do this, and does not check chache by default. Of course
> > tests have to be written to make use of cache, IIRC...
> 
> Slowness is a misguided argument as well.  Yes, configure is slow, but 
> you only have to run it if configure.in , config.h.in or config.make.in 
> chagnes. And that doesn't happen very often during development.

Slowness is a good argument. The config does change from time to time (you 
should know, IICC LilyPond had 36 changes in configure.in through 2006). 
And it is annoying.

Especially when you are trying to debug ./configure.

Ciao,
Dscho