Re: [jamboost] Re: [v2] ALL_LOCATE_TARGET capability?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-10 05:26:51

On Friday 10 December 2004 13:00, Toon Knapen wrote:

> > The problem is this this:
> >
> > Jamroot:
> >
> > lib my_lib : my_lib.cpp ..//some_other_project ;
> >
> > If you run
> >
> > bjam --build_dir=/tmp/foo
>
> We can make this as complex as we want. OTOH we can make it very simple
> too. For instance we (with our projects) use 1 env.var. to define where
> all 'derived objects' should go (e.g. ALL_LOCATE_TARGET). Every project
> specifies it's build-dir (in the project-rule) to be
> $(ALL_LOCATE_TARGET)/my-project-name.
>
> So it's also up to the boost-build project to be
> read-only-medium-friendly in this case.

Simplicity is a great advantage of this approach, I agree. I actually planned 
to use exactly it for Boost.

However, I also think that 'global-build-dir' feature is a desired one. I have 
many Gb of build directories scattered all over my home dir, and having just 
one build dir would be great. I even wonder if that won't cause faster 
builds, if build dir is on a different physical drive.

If global-build-dir can be specified from command line that would solve the 
problem of read-only-medium easily, since under my proposal full path to 
project is included in build dir location. 

Another remark about --build-dir. We cannot use declare id of the project, 
because it can lead to clashes when you have two copies of the same project. 
Imagine:

cd my_project
bjam --build_dir=foo --with_boost=1.32
bjam --build_dir=foo --with_boost=cvs

If build location for boost does not encode project location, we'll be 
building both boosts to the same place.... 

- Volodya