Re: [jamboost] Re: Build dirs and in-path features

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 + 
Boost.Build).

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

bin/debug/a

building with gcc will produce

bin/gcc/debug/a

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
> http://boost.org/boost-build2/doc/html/index.html and the pages with the
> new logo because I remember it (the bug tracker) lives zigzag.cs.msu.su
> but I had no luck. Finally I've found
> http://boost.org/tools/build/v2/doc/tracker.html and the address
> http://zigzag.cs.msu.su:7814/ 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'.

It's http://zigzag.lvk.cs.msu.su:7814/scarab/issues/id/BB37
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