RE: configure curiosities

["Howard Chu" <hyc@highlandsun.com>]

Thanks for the explanation, makes sense.

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.Org]

> 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
>