Boost logo

Boost-Build :

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.

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


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