[Date Prev][Date Next]
RE: Overlays configuration (Was: commit: ldap/ configure)
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.
> --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).
>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
>>>> I've thought a bit more on this; for each backend, I'd allow:
>>>> but only advertize
>>>> 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.