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

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

At 09:14 AM 4/19/2004, Kurt D. Zeilenga wrote:
>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,

Actually, we likely could process this argument
before or with others just by using the underlying
autoconf macros directly.

>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