From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-10 02:44:40
On Friday 10 December 2004 01:21, David Abrahams wrote:
> > or if you want to use an env.var.
> > BUILDDIR = [ modules.peek : ALL_LOCATE_TARGET ] ;
> > project my-project : : build-dir $(BUILDDIR) ;
> Well, thanks, but IMO this is bad. It should be an officially-supported
> command-line option for bjam. Projects shouldn't be expected to
> cooperate in choosing environment variables, and any project should be
> buildable from read-only media, including a project with dependencies on
> other projects also on read-only media.
I was thinking about this recently and almost decided that the approach Toon
has outlines is the right one. However, you're right that it's better to
have a standard name of an option.
The problem is this this:
lib my_lib : my_lib.cpp ..//some_other_project ;
If you run
then my_lib is compiled to /tmp/foo/bin/....., but where
does ..//some_other_project go?
Related to this, I think it would be great to have "global build dir". Say, I
have 3 copies of Boost, and several other non-so-small projects. They are
built in different places, so it's not easy to delete all build products.
I'd like to have directive like:
global-build-dir /space/p2/build_dir ;
which will causes all projects to be build under /space/p2/build_dir, with
Maybe, this will solve the "build from read only medium" issue too (if global
build dir can be specified from command line).
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