On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote:
Kurt Zeilenga wrote:
> On Feb 24, 2009, at 12:01 PM, richm(a)stanfordalumni.org wrote:
>> Kurt(a)OpenLDAP.org wrote:
>>> On Feb 23, 2009, at 5:08 PM, hyc(a)symas.com wrote:
>>>> I'm still uncertain about how configure should detect the NSS
>>>> though; they are not in any standardized location yet AFAICS.
>>> Like with other things, I would assume the environment to be
>>> to find the right NSS prior to running configure.
>> I'm not sure I understand what you mean by "environment to be
> CPPFLAGS, CFLAGS, ... and PATH environmental variables.
>> - How does openldap detect the header files for other components?
> autoconf is used, which uses the compiler to check if necessary
> headers are there, with the (additional to those built into the
> compiler) header path specified via CPPFLAGS.
> The idea here is to give the builder the freedom over which header
> directories are searched, and the order in which they are searched.
What's the usual way that openldap does this for packages installed in
non-standard locations e.g. if I want to have my own private build of
cyrus-sasl? Is it up to the user to specify
Does openldap configure have a
No. Because CPPFLAGS and LDFLAGS mechanism exists and provides more
control to the builder.
Perhaps a better question is - how would you like it to work?
I prefer that we leave the builder with as freedom as possible.
I'm assuming there must be some way specify which crypto you want
openldap with - is that a configure option?
Presently there is:
I assume we'd just add an 'nss' option to the above. However, Howard
might have other things in mind.
>> that both NSPR and NSS support pkg-config
> Here would be to ensure that the proper pkg-config is in the PATH.
> Of course, pkg-config stuff gets stuff into the environment in some
> fixed order, which does take away some freedom from the builder. I
> guess the builder can always manually adjust the order (by providing
> CPPFLAGS, etc., directly) and then provide a pkg_config which does
> little. So the freedom is there, just harder to take advantage of.
The original patch -
assumes the use of pkg-config - I suppose that is not sufficient.
My only concern would be whether or not pkg-config use here is
specific to a particular 3rd party packaging of NSS versus something
available with all installs of NSS.
I'll be leaving the actual technical review of your patch to Howard or
other active committers.