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