Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-14 03:41:36

On Saturday 11 December 2004 14:51, Zbynek Winkler wrote:

> >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.
> It means that if you switch compilers, add/remove flags etc. the files
> that should be rebuilt are rebuilt. For boost build this is true only to
> certain extent - only if you add feature that is represented in the
> build path. More on this at the end....

Yes, SCons has an advantage here because of MD5 signatures. Somebody has a
similar setup with jam, though. (Classic Jam + patches, not bjam +

> >Building into the current directory has some major disadvantages for
> >Boost developers who are trying to write multiplatform, multi-compiler
> >software.
> Sorry for not being clear on this either. I do not propose to build to
> the current directory all the time. I just think that it is very very
> nice to have the *option* to build to directories specific to
> variant/compiler but it would be IMHO better not to be forced to it.

Should this option be per-project, or per-user. And what do to with old
objects when you switch directory layout?

We probably can make all feature "non-symmetric". So, if you're builting with
a "default" toolset, it's not shown in path at all. Say, building with msvc
will produce


building with gcc will produce


But it will be inconvenient for persons with multiple toolsets. We're back to
question on how the option is specified.

> >>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?
> Yes.
> >I think you'd better be more explicit, particularly about what you mean
> >by too much/deep.
> I wanted to find the issue number in the bug database but I could not
> find it (the bug database). I've checked
> and the pages with the
> new logo because I remember it (the bug tracker) lives
> but I had no luck. Finally I've found
> and the address
> but that returns "HTTP Status 500". If you
> point me to a working bug tracker I'll find you the issue about
> 'cleaning too much/deep'.

Basically, if my_cool_app depends on boost, then bjam --clean will remove not
my my_cool_app objects, but also all of boost.

- Volodya


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