[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Overlays configuration (Was: commit: ldap/ configure)

> At 01:09 PM 4/18/2004, I wrote:
>>At 12:50 AM 4/17/2004, Pierangelo Masarati wrote:
>>>I was wondering if a --enable-overlays switch could be of interest.
>>I rather see --enable-overlays=auto --enable-overlays=automod
>>and likewise for backends.  The platform may not have all the
>>necessary features to support all backends and overlays. For
>>instance, I cannot build back-sql and back-perl on all
>>platforms I commonly development on
>>I think it better if the flag didn't mandate building of the
>>overlay/backend, but instead just indicated that it was
>>desirable.  Of course, that implies each individual
>>backend/overlay supported auto[mod] configuration.
> I'm thinking that the distinct between autoyes and automod
> should be implicit in auto.  That is, we really should
> just have [yes mod auto no] where auto attempts mod
> (if enabled) then yes.

Perhaps the issue is in "no": the way we just introduced
the --enable-backends option right now acts on the value
of each backend's enable switch, so there's no means to
determine whether a value of "no" resulted from the default
or from an explicit request from the user.  Otherwise, a
reasonable way to enable only those backends that can be
compiled would be to set to "yes" only those that were set
to "no" by default, leaving to "no" those explicitly set
by the user.  So, one could use --enable-backends=yes
and --enable-sql=no.  With the "auto" approach you suggest,
we should give backends the "auto" option again; then,
distinguish between "default-no" and "user-no".  At this
point, we could still leave most of the specialized backends
to "default-no", and have --enable-backends set them to
"auto/automod" to allow their build only if requrements are

Pierangelo Masarati