From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-04 03:55:03
> On Monday 03 March 2003 17:06, Vladimir Prus wrote:
> >liba is build with <optimization>off, so it builds boost with the
> > 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
> > 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
> 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
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