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

["Pierangelo Masarati" <ando@sys-net.it>]

>
>> 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
> met.

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.

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it