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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
