1 |
On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote: |
2 |
> On Mon, 29 May 2017 17:33:13 +0200 |
3 |
> Michał Górny <mgorny@g.o> wrote: |
4 |
> |
5 |
> > In the basic form, it can be used to conditionally force a specific |
6 |
> > flag to be enabled or disabled. For example: |
7 |
> > |
8 |
> > foo? ( bar ) |
9 |
> > |
10 |
> > would mean that the bar flag is implicitly enabled (forced) if foo is |
11 |
> > enabled as well. Appropriately: |
12 |
> > |
13 |
> > foo? ( !bar ) |
14 |
> > |
15 |
> > would mean that the bar flag is implicitly disabled (masked) in that |
16 |
> > case. |
17 |
> |
18 |
> All good here. |
19 |
> |
20 |
> |
21 |
> > It can also be used with multi-flag ??, ^^ and || constraints, i.e.: |
22 |
> > |
23 |
> > - ?? means that at most one of the flags can be enabled. If user |
24 |
> > configuration causes more than one of the flags to be enabled, |
25 |
> > additional flags are implicitly disabled (masked) to satisfy |
26 |
> > the constraint. |
27 |
> > |
28 |
> > - || means that at least one of the flags must be enabled. If user |
29 |
> > configuration causes none of the flags to be enabled, one of them is |
30 |
> > enabled implicitly (forced). |
31 |
> > |
32 |
> > - ^^ means that exactly one of the flags must be enabled. The behavior |
33 |
> > is a combination of both above constraints. |
34 |
> > |
35 |
> > The automated solving of USE constraints would require the developers |
36 |
> > to consider the implicit effect of the constraints they are writing. |
37 |
> |
38 |
> |
39 |
> Can you provide an efficient algorithm for the above syntax? |
40 |
> That is, given a set of +/- useflags forced by user, output the set of |
41 |
> effective useflags (or a rant if it is inconsistent). |
42 |
|
43 |
I'd rather leave that to people who are good with algorithms. I find |
44 |
the whole thing scary but I don't really see a sane alternative here. |
45 |
Worst case, we have to figure out some arbitrary limitations to keep |
46 |
things sane. |
47 |
|
48 |
> Maybe I'm mistaken, but I doubt it is possible with n-ary constraints. |
49 |
> |
50 |
> Now the extra question: Do those n-ary operators have any advantage ? |
51 |
|
52 |
Yes, they do. They improve readability, compared to cascades of plain |
53 |
constraints. I'm pretty sure users will be happier to see 'you need to |
54 |
select one of foo, bar, baz' than 'if foo is disabled, then ...' |
55 |
|
56 |
> The point is to express some preference, below you suggest to leave |
57 |
> that to the user, but what about leaving that to the ebuild developer? |
58 |
|
59 |
Well, I don't find that a killer feature but I don't see a reason to |
60 |
take it away either. Either way we have some risks, especially when USE |
61 |
dependencies and blockers are involved. In both scenarios, I find it |
62 |
less risky to let user control the order than to rely on all developers |
63 |
respecting the same preference order. Not saying the latter wouldn't |
64 |
hurt anyway but the users would at least have an easy way out. |
65 |
|
66 |
> That way, e.g., || can be rewritten as implications: '|| ( a b c )' |
67 |
> becomes '!b? !c? a' meaning if none is enabled then a is automatically |
68 |
> enabled. |
69 |
|
70 |
Unless you are planning to cache the rewritten forms, I don't see |
71 |
a problem, really. You just reorder the flags according to the apparent |
72 |
preference before rewriting. |
73 |
|
74 |
> |
75 |
> Note that with only unary constraints, computing the set of effective |
76 |
> useflags becomes trivial (linear in the # of useflags + constraints): |
77 |
> take the constraints as a list, solve the first one, add its |
78 |
> consequences (if any) to the set of forced useflags, continue with next |
79 |
> constraint or rant if the set of forced flags is inconsistent. |
80 |
|
81 |
Sounds fine. But I'm not an expert to really judge that ;-). |
82 |
|
83 |
-- |
84 |
Best regards, |
85 |
Michał Górny |