Re: [jamboost] Re: [V2] Problems with setting <exception-handling>off with msvc

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
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2