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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

This sounds overly complex.

I think each backend/overlay should have options:
        [yes mod auto no]
with an appropriate default, generally 'no', with
one or two 'yes' (namely for back-bdb).  If 'auto',
configure would first attempt to configure the
code as a module, next built-in, otherwise no.

I view the --enable-backends/--enable-overlays should
mean "automatic enablement of ..." have options:
        [yes no]
with no being the default.  If 'yes', then each
backend/overlay would implicitly take the value
'auto' (unless already set to 'yes' or 'no').

It is unforunate with configure that we couldn't
process this argument before others, so in:
        --enable-backends --enable-bdb=no

the $ol_enable-bdb will set to 'auto'.  This,
I think, is fine.  I don't see --enable-backends
ever being released, it's just a hack to make it
easier on developers (and a hack which should
not make it into releases).

Kurt

At 05:31 AM 4/19/2004, Pierangelo Masarati wrote:

>>> -----Original Message-----
>>> From: owner-openldap-devel@OpenLDAP.org
>>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo
>>> Masarati
>>
>>> I've thought a bit more on this; for each backend, I'd allow:
>>>
>>> user_no|no|auto|yes|mod|user_yes|user_mod
>>>
>>> but only advertize
>>>
>>> no|auto|yes|mod
>>>
>>> and only use no|yes as defaults
>>>
>>> with either no|auto|yes used as default.
>>> When the user picks any of no|yes|mod,
>>> the user_* from should be assigned to the
>>> configure var.
>>>
>>> - auto|yes|mod means specific backend build
>>>   is allowed not to take place if requirements
>>>   are not met without global build failure;
>>> - no|user_no means specific backend build
>>>   must not even be attempted
>>> - user_yes|user_mod means global build must
>>>   fail if specific backend requirements are
>>>   not met.
>>>
>>> --enable-backends should take the values
>>> no|yes|mod, where:
>>> - no means promote all yes to no
>>> - yes means promote all no to yes
>>> - mod means promote all yes|no to mod
>>>
>>> As a consequence, --enable-backends replaces
>>> backends' defaults with other legal default
>>> values, does not affect specific explicit
>>> backend enables and causes enabled backends to
>>> compile only if requirements are met.
>>>
>>> If there's no objection, I'd start coding this.
>>
>> Hm, I need to think some more about this.
>>
>> There are only two default states: no and yes, but not mod.
>> There are three user states: no, yes, and mod.
>> I think there are also two auto states: auto,yes and auto,mod. Currently
>> none of our backends default to an auto.
>>
>> To me, using enable-backends=no means "turn all backends off" which of
>> course is senseless because then slapd cannot be built. You're treating
>> it as "turn all default-yes backends to user-no" which I guess is more
>> useful, but less intuitive.
>
>Mmmmh, I guess I stated it badly; I'm treating enable-backends=no
>to turning all backends to "no"; this should only be used in
>conjunction with enable-<somebackend>=yes.  If more than one defaults
>to yes, or if we add "auto" (which I encourage), then someone could
>desire: disable all those that default to "yes" or "auto", except those
>that are explicitly enabled.
>
>>
>> Then, enable-backends=yes in light of this discussion would mean set all
>> default-no backends to auto,yes, and enable-backends=mod would mean turn
>> all default-yes and default-no backends to mod.
>>
>> Does that follow?
>
>More or less, yes.  This would be exactly the opposite of "=no", i.e.
>enable all those that would default to no.  The important distinction, is
>that those enabled by enable-backends should be build only if possible. 
>I.e., if I don't have libiodbc installed, and I enable all backends, I
>don't want the build to fail because back-sql cannot be built.  I simply
>want it to be skipped (maybe with a warning) but all else be built.
>
>p.
>
>-- 
>Pierangelo Masarati
>mailto:pierangelo.masarati@sys-net.it