On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote: > On Mon, 29 May 2017 17:33:13 +0200 > Michał Górny <mgo...@gentoo.org> wrote: > > > In the basic form, it can be used to conditionally force a specific > > flag to be enabled or disabled. For example: > > > > foo? ( bar ) > > > > would mean that the bar flag is implicitly enabled (forced) if foo is > > enabled as well. Appropriately: > > > > foo? ( !bar ) > > > > would mean that the bar flag is implicitly disabled (masked) in that > > case. > > All good here. > > > > It can also be used with multi-flag ??, ^^ and || constraints, i.e.: > > > > - ?? means that at most one of the flags can be enabled. If user > > configuration causes more than one of the flags to be enabled, > > additional flags are implicitly disabled (masked) to satisfy > > the constraint. > > > > - || means that at least one of the flags must be enabled. If user > > configuration causes none of the flags to be enabled, one of them is > > enabled implicitly (forced). > > > > - ^^ means that exactly one of the flags must be enabled. The behavior > > is a combination of both above constraints. > > > > The automated solving of USE constraints would require the developers > > to consider the implicit effect of the constraints they are writing. > > > Can you provide an efficient algorithm for the above syntax? > That is, given a set of +/- useflags forced by user, output the set of > effective useflags (or a rant if it is inconsistent).
I'd rather leave that to people who are good with algorithms. I find the whole thing scary but I don't really see a sane alternative here. Worst case, we have to figure out some arbitrary limitations to keep things sane. > Maybe I'm mistaken, but I doubt it is possible with n-ary constraints. > > Now the extra question: Do those n-ary operators have any advantage ? Yes, they do. They improve readability, compared to cascades of plain constraints. I'm pretty sure users will be happier to see 'you need to select one of foo, bar, baz' than 'if foo is disabled, then ...' > The point is to express some preference, below you suggest to leave > that to the user, but what about leaving that to the ebuild developer? Well, I don't find that a killer feature but I don't see a reason to take it away either. Either way we have some risks, especially when USE dependencies and blockers are involved. In both scenarios, I find it less risky to let user control the order than to rely on all developers respecting the same preference order. Not saying the latter wouldn't hurt anyway but the users would at least have an easy way out. > That way, e.g., || can be rewritten as implications: '|| ( a b c )' > becomes '!b? !c? a' meaning if none is enabled then a is automatically > enabled. Unless you are planning to cache the rewritten forms, I don't see a problem, really. You just reorder the flags according to the apparent preference before rewriting. > > Note that with only unary constraints, computing the set of effective > useflags becomes trivial (linear in the # of useflags + constraints): > take the constraints as a list, solve the first one, add its > consequences (if any) to the set of forced useflags, continue with next > constraint or rant if the set of forced flags is inconsistent. Sounds fine. But I'm not an expert to really judge that ;-). -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
