Boost logo

Boost-Build :

Subject: Re: [Boost-build] Effect of usage requirements vs. default values of a feature
From: Vladimir Prus (ghost_at_[hidden])
Date: 2011-04-16 17:12:12

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
> 2. Conditional requirements in usage-requirements where produced property's
> feature is non-free
> 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.

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.

- Volodya

Vladimir Prus

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at