Re: Build dirs and in-path features

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-11 00:47:47

Zbynek Winkler wrote:
> While reading some previous posts related to build dirs I thought I chip in.
> 
> I think scons is more intuitive regarding this issue. By default it 
> builds to the same dir 

The same dir as what?

> *but* it also computes hash of all commands used 
> to build a certain file. If the user desires a different build dir can 
> be specified (a variant can be created).

What does the hash have to do with this?

I think i actually know the answer, but it's only because I understand
how Scons works -- what you've written above seems pretty disconnected.

Building into the current directory has some major disadvantages for
Boost developers who are trying to write multiplatform, multi-compiler
software.

> This has several nice properties. The most important (at least for me) 
> is that if you change the SConscript (Jamfile) the relevant files are 
> rebuilt. This very thing hits me again and again. 

We've had plans for a long time to make targets dependent on the
Jamfiles that specify them. That wouldn't preserve Scons' nice property
that you can edit the SConscript in benign ways (like adding comments)
without causing a rebuild.

> Combined with the fact 
> that "--clean" or "-a" options behave strange (clean too much/deep), it 
> is very hard to use. 

I suppose you're talking about Boost.Build now instead of Scons?
I think you'd better be more explicit, particularly about what you mean
by too much/deep.

> Also the build hierarchy of scons is more intuitive 
> and the built files can be more easily found. [if only scons had 
> user-requirements I'd really consider switching...]
> 
> What is your view of this? Do you think that the complicated build dir 
> structure has some important properties that I do not see? Is it 
> superior in some way?

It allows you to easily keep builds with different variants, compilers,
and options separate so that you can pursue a compile/edit/debug cycle
without rebuilding the world each time you're interested in looking at
something new. It's very common for me to fire off a single bjam
command that tests a library against ten or eleven different compilers.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com