Subject: Re: [Boost-build] Effect of usage requirements vs. default values of a feature
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-04-16 17:29:13
On 04/16/2011 02:12 PM, Vladimir Prus wrote:
> On Saturday, April 16, 2011 21:29:56 Gevorg Voskanyan wrote:
>> Steven Watanabe wrote:
>>> Unfortunately, you aren't allowed to put
>>> non-free features in usage-requirements.
>>> I'd like it to work, but I'm not sure how
>>> to specify exactly what the behavior should
>>> be in all cases.
>> Thanks Steven, that really is unfortunate. The doc doesn't mention this
>> limitation IIRC.
>> I can see these complicating factors:
>> 1. Which source alternatives get selected depends on values of non-free
>> features in requirements
Declare it an error if applying usage requirements
would cause a different main target alternative
to be selected? Actually, an even easier solution would
be: if the usage requirements that reach a main target
contradict its requirements, then it is an error.
>> 2. Conditional requirements in usage-requirements where produced property's
>> feature is non-free
Recheck conditional features? That shouldn't be
>> Do you see other problems which need to be thought about?
> Well, the biggest problem is that if you have metatarget T, which depends on
> metatargets A and B, and you build A first, and then build B, and it returns
> some non-free features as usage requirements, it means that potentially generation
> of A must be redone, recursively.
We could only apply the usage requirements to
direct ancestors. Isn't that how it works now
for free features, anyway?
> I don't have a formal proof, but I think that the problem of determining right
> set of build properties for all metatarget, if non-free usage requirements is
> allowed, would be essentially as complex as SAT. And while we can use SAT solvers,
> I am very sceptical about using such complicated machinery -- we might arrive
> at answer that is correct, but totally opaque to the user.
> So, I suspect that if we're to allow non-free features in usage requirements,
> we need to invent some heuristics that would work in practical cases without
> requiring exponential iteration over all metatargets.
> I'd be thrilled to have real discussion about this problem.
Okay. To start off, another example that we'd like to
make work: Boost.Test uses <toolset>msvc:<async-exceptions>on
in its usage requirements, and this has been broken
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk