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...
> I wonder if we could satisfy
> most people with a configure script -- maybe not based on autoconf --
> that is limited in scope to just the things that are currently tweakable
> in the git Makefile.
The problem with handcrafted configure script lies in the portability
of it. There was an attempt to add such script, IIRC based on mplayer's
configure.sh script, but it turned out it was not portable enough.
The conclusion was that sice so many manhours were put into making
autoconf generate ultra-portable ./configure shell script, it would
be better to use it.
> If configure ran only, say, 10-15 tests, I bet the fork+exec overhead on
> Cygwin would be perfectly tolerable.
That's not only fork+exec, that is also the fact that large number
of tests relies on compiling snippets of code...
P.S. What do you think about separating the guessing appropriate
values of build variables based on uname to separate file
config.mak.guess, included in Makefile?
--
Jakub Narebski
Poland
-
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
