From: David Abrahams (dave_at_[hidden])
Date: 2004-12-10 11:01:38
Vladimir Prus wrote:
> 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
> bjam --build_dir=/tmp/foo
> then my_lib is compiled to /tmp/foo/bin/....., but where
> does ..//some_other_project go?
You should take a page from the BBv1 cross-project build system.
my_lib goes in
and the rest goes in
You don't need a directory called "bin."
> 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
> paths like
> Maybe, this will solve the "build from read only medium" issue too (if global
> build dir can be specified from command line).
I agree that this would be useful; it could be put in xxx-config.jam
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
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