Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-28 09:03:08


Juergen Hunold <hunold_at_[hidden]> writes:

> Hi Dave !
>
> On Saturday 25 June 2005 15:01, David Abrahams wrote:
>> Jürgen Hunold <hunold_at_[hidden]> writes:
>> > This boils down to Boost.Test,
>> > which contains
>> >
>> > alias minimal : : : :
>> > <toolset>msvc:<asynch-exceptions>on
>> >
>> > which Boost.Build tries to build, because it is not explicit.
>>
>> What's weird about this is:
>>
>> What does it mean to build an alias??!
>
> Well, I'm sorry, the right term would have been "evaluated".
>
>> I think the right fix would address that problem.
>
> Okay, I'll try to explain this more carefully.
>
> It all starts in $BOOST_ROOT/Jamfile.v2 line 191
>
> -------- snip ------------------
> # Just build the libraries, don't install them anywhere.
> # This is what happend with just "bjam --v2".
> alias build_all : libs/$(libraries)/build ;
> ----snap--------------
>
> When doing a <use>/boost in my own Jamfiles, V2 therefore evaluates
> _all_ Jamfiles.v2 in _all_ $libraries.

Fine so far.

> Side-note:
> This "feature" can be disabled by making "build_all" explicit. But then
> the usage-requirements of Boost are not added to the properties of my
> projects. This was the trap I ran into last week...

That sounds like a problem right there. The usage-requirements of the
Boost projects should be added to the properties of all projects that
"use" boost and no others, regardless of whether targets in Boost are
explicit.

> In case of Boost.Test V2 then scans libs/test/Jamfile.v2 and finds the
> minimal alias. This normally looks
>
>> > alias minimal : : : :
>> > <toolset>msvc:<asynch-exceptions>on
>
> and If I comment the "::::" line I get the more readable
>
> alias minimal
> : # sources
> : # requirements
> : # default-build
> : # usage-requirements
> <toolset>msvc:<asynch-exceptions>on
> ;

Right.

> This declares an alias which has an usage-requirement which is then
> dutifully added to the property set of _my_ projects.

Uh, why??

That sounds like the problem again. The usage requirements of minimal
should only be added to the properties of projects and targets that
"use" it, regardless of whether it's explicit.

> In the normal case (<exception-handling>on) this adds
> <asynch-exceptions>on to _my_ project.
> Pretty cool, isn't it ?

No, that's broken.

> And this leads to:
>
>> > cl : Command line warning D4025 : overriding '/EHs' with '/EHa'
>> > baseio.cpp
>> > This is clearly a misconfiguration and also fixed by the patch.
>
> Or course this adds "asynch-exceptions-on" the build-path, too.
>
> When building with <exception-handling>off , "minimal" also injects
> <asynch-exceptions>on in my project

Which shouldn't be happening.

> and V2 then correctly detects that it can't build this combination.
>
>> How does the patch fix that? It's non-obvious to me.
>
> Making "minimal" explicit prevents V2 from evaluating it and addings its
> usage-requirements to my projects.
>
> I've had several discussions with Volodya about this behaviour.
> It has more pros then cons

Well if so, the behavior and its rationale had better be clearly
documented somewhere, because as far as I'm concerned it's utterly
confusing.

> and I would not mess with it before 1.33.0 is
> out and then its frozen anyway.
> So, please:
>
> 1. Remove "minimal" or document what it is for and where it is used.

It represents the header-only "minimal" configuration of the test
library (boost/test/minimal.hpp). I'm not going to remove it; where
do you think documentation should go?

> 2. make it explicit and document it.

I don't like making changes whose consequences I don't even think I
understand. At least when I added minimal, I thought I knew what I
was doing. What you're telling me sounds like either BBv2's response
to usage-requirements is completely broken or its documentation is (I
suspect both, actually).

After we deal with the issue of how BBv2 works I'll be happy to do
whatever needs to be done to make that Jamfile work for you.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
 

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