Re: [jamboost] [V2] Some usage results

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
<optimization>off. 

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