How to correctly hadle optional_depends?

[Auke Kok]

On 06/25/2011 05:15 AM, Zbigniew Luszpinski wrote:
>>
>> isn't there a -DWITH_... option for this?
>>
>> please, let's not add anymore optional_depends with empty $3....
>>
>> Auke
>
> The only thing I found is BUILD_printer-applet=ON
> but this is the result of autodetection.
>
> If optional_depends with empty parmaters is not welcome what to do if
> there is no parameter to activate because decision is based on
> autodetection?

here's how it works

$2 == enable feature flags
$3 == disable feature flags

We have these scenarios:

(a) $2 non-empty $3 non-empty
(b) $2 empty $3 non-empty
(c) $2 non-empty $3 empty
(d) $2 empty $3 empty


In case (a) it's obvious that the application will properly compile with 
AND without the dependency, so no issue

In case (b) it's obvious that the application will build properly with 
(due to autodetection) and without (due to --disable flags), so no issue

In case (c) it's a bit harder, but given the fact that $2 is non-empty, 
we can somewhat safely assume that autodetection doesn't work here, 
since it was needed to provide $2, and so, no issue: the application 
will likely build fine with and without the dependency.

In case (d), we have no choice: Either people said "yes" and 
autodetection must be working (otherwise the dependency won't even be 
ever used), so there's no choice. Or people said "no", but guess what: 
The chance that $1 is already installed anyway is realistic, and, thus, 
the user has no choice but to enable $1 anyway.

And, as a matter of fact, lunar will even just skip the question for $1 
if ($2 and $3 are empty), just because it's a nonsense question in that 
case.

>
> When building modules I see 3 types of configure parameters:
> both options present: enable/disable with/without - this is supported by
> Lunar all optional_depends fields can be filled in.
>
> only 1 option present: enable or disable, with or without - this way one
> parameter of optional_depends fields have to be left empty.
>
> none option present - configure is fully based on autodetection - for
> example ntrack module. To force disable some options you have to sedit
> configure.

and this is what I'm trying to get rid of. Since a regular desktop 
quickly has 300-400 applications, these dependencies just start to creep 
into your system, and worse, trying to get rid of them is really hard.

>
> BTW. Another situation when I do not know what to do. ntrack module
> depends on one of libnl: libnl or libnl2 or libnl3 when only one of these
> is required. How to design optional_depends this case? You can not use
> alias to select one permanently because some modules use libnl, other
> libnl2 another libnl3 depending on how fresh given module is.

Choose the one that makes the most sense, and stop using the other 
versions. We have to make choices for the users at some point - there's 
no reason to support <world> with only 10 developers, we just can't do that.

Auke