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

From: Juergen Hunold (hunold_at_[hidden])
Date: 2005-06-30 14:39:05

Hi Dave !

On Thursday 30 June 2005 14:53, David Abrahams wrote:
> Juergen Hunold <hunold_at_[hidden]> writes:
> > Well, usage-requirements just work as expected (at least by me
> > ;-)).
> >
> > The "surprise" seems to be the way "use-project" works.

> > When I do "use-project /boost", _all_ Boost Libraries are put into
> > scope
>
> They are "declared;" I wouldn't call that putting them "into scope."

Well, their Jamfiles are loaded, parsed and well, analysed.
I would call this "evaluted" but I'm no BBv2 guru, just someone trying 
to use it ;-))

> > via $BOOST_ROOT/Jamfile.v2 line 170 ff.
> > --- snip -----
> > # Make project ids of all libraries known.
> > for local l in $(libraries)
> > {
> > use-project /boost/$(l) : libs/$(l)/build ;
> > }
> > -- snap ---
> >
> > Then Boost.Test Jamfile.v2 is loaded and all targets found in it
> > are evaluated
>
> "declared."
>
> > and their usage-requirements added to the current property set.
>
> "Current property set?" What is that? There is no property set
> statefulness AFAIK.

Well, I don't know the exact definition, but what I *mean* is the set of 
requirements of _my_ project. This is where "<asynch-exception>on" ends 
and causes havoc. 

> > Since the "minimal" is not explicit, it is evaluated
>
> It is declared.
>
> > and it's usage-requirements added.
>
> And that's where the problem is.

Yes. 

> > Thats all there is. Works as designed.
>
> You've said that before but I see no evidence that the adding of
> usage-requirements to properties of targets in that step was an
> explicit design choice. As I said, I need to
>
> a. See it in the BBv2 documentation
> b. See a darned good rationale for that behavior
>
> before I'm ready to accept that.

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'm not sure this was an "explicit" design choice.
It _can_ be a mere oversight when implementing "alias" since its a newer 
feature as usage-requirements.

I believe there might be use-cases when this "surprising" behaviuor 
might be wanted. 

On the other hand, "use-project" always meant "this projects Jamfile and 
its contents" to me. So, I'm not surprised at all ;-))

But, please ask Volodya on his view about this...

> > When writing "minimal" you probably wanted it's usage requirements
> > only added when someone adds /boost/test//minimal to her project,
> > right ?
>
> Yes.

Good. At least I got this one right ;-))

> No, you've added nothing to what I knew before. You're telling me
> that making the target explicit will make everything work again.
> Wonderful! As I said, I will be happy to make whatever adjustments
> are necessary after we deal with the issue of how BBv2 works. The
> behavior you're describing is counterintuitive and surprising and I
> don't want to paper over the problem by making a change I don't
> understand. 

Before we spent a long time "papering over" this issue, I hacked a small 
example test case and demonstration and hopefully attached it.

It consists of three parts:

a) used-project (original Boost.Test)
which contains two aliases:
implicit-alias (Boost.Test "minimal" alias)
explicit-alias (my proposal) 

b) implict-usage 
just uses "used-project"
c) explicit-usage
adds "<source>used-project//explicit-alias" to its sources.

I've defined two dummy features "have-implicit" and "have-explicit" 
which will be added to the build-path when set to "yes" just to have a 
"visible" feedback and don't have to use some -d+X option...

Output from building "implicit-usage":

--- snip ---
cd /home/hunold/tmp/bbv2/implict-usage/
bjam gcc-3.4
...found 9 targets...
...updating 6 targets...
MkDir1 bin
MkDir1 bin/gcc-3.4
MkDir1 bin/gcc-3.4/debug
MkDir1 bin/gcc-3.4/debug/have-implicit-yes
gcc.compile.c++ bin/gcc-3.4/debug/have-implicit-yes/main.o
gcc.link bin/gcc-3.4/debug/have-implicit-yes/explicit-usage
...updated 6 targets...
--- snap ---

Output from running "explicit-usage":
--- snip ---
cd /home/hunold/tmp/bbv2/explicit-usage/
bjam gcc-3.4
...found 10 targets...
...updating 7 targets...
MkDir1 bin
MkDir1 bin/gcc-3.4
MkDir1 bin/gcc-3.4/debug
MkDir1 bin/gcc-3.4/debug/have-explicit-yes
MkDir1 bin/gcc-3.4/debug/have-explicit-yes/have-implicit-yes
gcc.compile.c++ 
bin/gcc-3.4/debug/have-explicit-yes/have-implicit-yes/main.o
gcc.link 
bin/gcc-3.4/debug/have-explicit-yes/have-implicit-yes/explicit-usage
...updated 7 targets...
--- snap ---

Please note that "used-project" itself has no usage-requirements itself.

When you replace "have-implicit-yes" with "asynch-exception-on" you get 
the behaviour that I encountered.

> This should stick out like a sore thumb until we figure
> out how BBv2 is really supposed to work and be explained.

Well, if you want to find out "how BBv2 is really supposed to work" I 
think you better ask Volodya or dig through the archives. 

Unfortunately, I can't afford to spent more time on BBv2 in the past and 
in the foreseeable future and so I still have no deeper understanding 
of the V2 language itself, to my deep regret :-((
So I just try to "use" it and help iron out bugs when I encounter them.
And so I'm also tied to the "observeable" behaviour ...

Yours, 

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau
* voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover 
* fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover
* hunold_at_[hidden] ! www.ive.uni-hannover.de
 --Boundary-00=_apExCVtVihaV2vs Content-Type: application/x-tgz;
name="bbv2.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="bbv2.tar.gz"
[Attachment content not displayed.] --Boundary-00=_apExCVtVihaV2vs--