From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-03 11:06:34
Jürgen Hunold wrote:
> Hi !
> I've tested library dependencies and the basically work. I've got my
> external libx and add dependencies to it by specifiying
> <dependency>@/libx/libx (test case attached, as usual ;-))
> But I made an interesting observation: In my program, I need to have
> three files compiled and linked _without_ optimization. I've simulated
> this in the example by compiling bjam/main/liba with <optimization>off.
> When I bjam --v2 bjam/main, I end up with libx recompiled _without_
> optimization. Of course bjam correctly updates the "normal" libx, too.
> To test this further I've added a dependency to Boost by adding a
> use-project/dependency pair to bjam/main/Jamfile. Then I end up with
> all boost libraries compiled with
> My question is: Is this a bug or a feature ? If this is the correct
> behaviour, this would mean that I end up with a specialized version of
> every external library. And this would waste lots of disk space.
This is the correct behaviour. The docs, in "Using libraries", say:
Which properties must be used for "lib1"? The answer is that some properties
are propagated - Boost.Build attemps to use dependencies with the same value
of propagated features. The <optimization> feature is propagated, so both
"app" and "lib1" will be compiled with full optimization.
liba is build with <optimization>off, so it builds boost with the same
property. I agree that this is bad idea in this case, but I think you should
use a different mechanism. Consider:
exe hello : hello.cpp a ;
obj a : a.cpp : <optimization>off ;
This will build hello as usual, and a.obj without optimization. Even if hello
depends on some libraries, they will be compiled in the usual way. I attach
an example, please use "bjam release" to see the results.
Do you have any problems with this approach (except that it's not documented
> I've encountered several problems using <dependency>@/boost. First,
> $BOOST_ROOT/Jamfile.v2 has no usage-requirements. I think there should
> be at least <include>. ;-)
Agh... you are right. Fixed.
> Second, it seems impossible to mix Jamfile and Jamfile.v2 names. I tried
> to specify file-order in bjam/main/boost-build.jam using
> JAMFILE = [jJ]amfile.v2 [jJ]amfile ;
> but this did not work, bjam V2 is trying to use V1-Jamfiles and V2
> Jamfile.v2 in boost tree in random order. I think this is a temporary
> issue, but annoying none the less.
> The only solution was to (re-)move all V1-Jamfiles out of the way.
Yep, this output says it all
WARNING: Found multiple Jamfiles at this '/home/ghost/Work/boost' location!
Loading the first one: ' Jamfile '.
Guess the problem is that 'Jamfile' comes first in directory listing. I've no
opinion as to wether we should use the first matched pattern.
I've being using a "shadow" boost tree for V2, which contains only Jamfile and
refers to real source dirs for some time. Don't know if this is of any help,
but it's attached. Jamfiles there are named "Jamfile".
> The third problem is that I don't seem to have a shared python2.2
> library, but I'll try to get it on monday ;-) Static linking works, of
Shared linking works for me as well. Waiting for problem description ;-)
> And I would like to know more on the status of the msvc-toolset.
> I've tried to compile some projects during the last week, but did not
> succeed. Before I post false bugs again, I'd like to have an
> "inofficial" status.
We're in process of making the regression suite pass on msvc, and are about
1/4 through the way (the test system needs some tweaking to handle many
toolsets). I think once all tests pass the toolset can be declared usable.
--------------Boundary-00=_YQK63EUB2RMGD3JHJHWT Content-Type: application/x-tgz;
Content-Disposition: attachment; filename="specific.tar.gz"
[Attachment content not displayed.] --------------Boundary-00=_YQK63EUB2RMGD3JHJHWT Content-Type: application/x-tgz;
Content-Disposition: attachment; filename="boost-v2.tar.gz"
[Attachment content not displayed.] --------------Boundary-00=_YQK63EUB2RMGD3JHJHWT--
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