Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-07-04 09:25:08

On Friday 01 July 2005 07:18, David Abrahams wrote:

> > a. It seems to be missing, at least from my CVS version of the docs.
> > And I have trouble getting it built.
> > b. Ask Volodya ;-))
> Well, I've been expecting him to weigh in here and I'm wondering why
> he hasn't. Volodya?

Initially I though you'll two will figure out everything ;-)

> > Well, I'm not sure this was an "explicit" design choice.
> Well, now that's a different story than you were telling me before.
> > It _can_ be a mere oversight when implementing "alias" since its a
> > newer feature as usage-requirements.
> Well, I'd be surprised if this had anything to do with "alias."
> Doesn't it work the same way for built library targets?
> > I believe there might be use-cases when this "surprising" behaviuor
> > might be wanted.
> I don't. Or if there are such cases, they should be handled via a
> more explicit and direct mechanism.
> > On the other hand, "use-project" always meant "this projects Jamfile
> > and its contents" to me. So, I'm not surprised at all ;-))
> But that's crazy! The fact that you need library X from project A
> shouldn't cause all of the usage-requirements from libraries Y and Z
> in project A to be applied to everything in your project.

I think the situation is that Jurgen has <use>/boost somewhere. That, in turns
builds every single target in Boost, and propagates usages requirements back
to the dependent. Including that <async-exceptions> thing.

The right solution is a combination of:

1. <use>-in only the needed libraries
2. Add "alias headers ; " to top-level Boost Jamfile.v2, and
<use>/boost//headers. This way, you'll get <include> usage requirements from
top-level Jamfile.v2, and nothing else.

- Volodya

Vladimir Prus
Boost.Build V2:

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