Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-04 03:55:03

Hi Jürgen,

> On Monday 03 March 2003 17:06, Vladimir Prus wrote:
> >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 ;-) )
> Actually no. It would even be better, because it elimintates one
> library.
> But this does not work as you wrote. It still builds boost and any---
project-root.jam 1 Oct 2002 16:31:31 -0000 1.1
+++ project-root.jam 4 Mar 2003 08:24:39 -0000
@@ -1,3 +1,6 @@

import gcc ;
import foo ;
+import toolset : using ;
+using msvc : 6.5 : /foo/bar ;

> <depency> library with optimization-off. You can reproduce this by
> modifiying liba/Jamfile from my last test case to use your method.
> It seems bjam constructs a "main-target-obj" for each obj, which is in
> turn dependent on libx with optimization-off.

You are correct with your analysis. Here, "a" object is created without
optimization. Since all main targets inherit <dependency>@/boost, this
one builds boost, and since <optimization>is propagated, builds it with

Oh, V1 was so simple... no usage requirements, not multiple projects.. ;-)

Anyway, I can see three things that contribute the the problem:
1. Global <dependency> requirement. Not so bad idea.
2. The fact that <dependency> feature cause the build of everything
in boost. In this case, object file creation does not depend on boost,
so we need not rebuilding. OTOH, <dependency> features explicitly state
dependency on something, so we shouldn't be overly smart.
3. No matter how hard you try, <optimization> is propagated. Now I'm not sure
this is right. You can request a specific version of library

exe a : a.cpp l/<optimization>space ;

but you cannot request specific properties for compiling "a.cpp", without
affecting "l". I don't like this assymetry.

The best idea, IMO, is to fix 3: introduce 'local requirements', which are not
propagated. Opinions?

- Volodya


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