[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: configure curiosities
At 05:32 PM 5/26/99 -0700, Howard Chu wrote:
>These aren't vital questions to answer, but after examining the configure
>and configure.in files, I got curious:
> why is the config.cache explicitly disabled?
More often than not, folks rerun configure because they have
changed their environment. The slightess of which invalidates
the cache. This reduces "I installed X and configure didn't
detect it" or "I added CPPFLAGS=-DFUBAR and configure screwed
up" like complaints.
There have been a few interesting discussions on the autoconf
mailing lists on this subject (~apr99).
> why is cc preferred over gcc?
Because thread detection is much easier using the system
compiler. Guessing what needs to be specified when CC=gcc
is problematic. When the user chooses CC=xxx, she assumes
the responsibility to set all appropriate flags.
> why is the install program explicitly checked, twice?
bug, fixed.
>I think it's somewhat tedious to have to re-run the entire configure script
>every time I want to enable or disable a single backend in slapd. Having all
>of the tests cached would help speed this up a little.
I recommend that developers use separate object trees for testing
separate environments. I often have a half dozen different
configurations around for testing this and that. See VPATH
section of ldap/INSTALL.
>In general I prefer gcc over whatever vendor-supplied cc is available (even
>if the native compiler is already gcc; frequently I will have installed a
>newer version than the OS distribution included). Are there known problems
>with gcc that make cc the better choice?
It's been my experience that detection of vendor provided headers
and libraries is easier using vendor provided compiler. This is
especially evident with pthread headers and libraries.
Kurt