[Date Prev][Date Next]
RE: Overlays configuration (Was: commit: ldap/ configure)
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:
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:
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.