Re: [Boost-build] Effect of usage requirements vs. default values of a feature

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

AMDG

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
too hard.

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

In Christ,
Steven Watanabe