Re: How to suppress toolset in target paths?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-27 11:58:27

Vladimir Prus wrote:
> An example relevant to this question is:
> 
> 
> 1. You have .y -> .h transformation chain, which does not
> depend on any properties at all.
> 
> 2. You build debug and release version and get 
> bin/debug/gcc/a.obj
> bin/debug/gcc/b.obj
> bin/parser.h
> 
> 3. You run 
> 
> bjam --clean debug
> 
> and "bin/parser.h" is removed too, because it's in dependency graph of
> debug variant.
> 
> 4. You run 
> 
> bjam release
> 
> and now all your files which include parser.h are rebuild too.
> 
> IIRC, this is the behaviour Jurgen did not like. 

I understand that. I guess the easy solution is that cleaning with a
build request only removes targets for whom the non-free features of the
build request appear in the target path. So "bjam --clean debug" would
not remove bin/parser.h. If you want to remove that you need "bjam
--clean all" or perhaps "bjam --deepclean debug," which ensures that all
targets associated with the debug target are cleaned.

> My current idea is that we should use 'flags' rules to detect which properties 
> are in path, but also provide "<in-path>" feature which can control it.
>
> 1. <in-path>python-version adds the mentioned feature to the path
> 2. <in-path>all adds all the base (non-free) features to the path
> (giving current behaviour)
> 
> Thoughts?

#1, I don't see how that's relevant to Jurgen's problem. But maybe you
never meant it to be? If so, it would be good to spin Jurgen's problem
off into a separate thread.

#2, I don't see a need for <in-path>, and it adds complication. I think
you should be far more parsimonious about adding flexibility to BBv2.
Wait until people need the flexibility and then do not overgeneralize it
-- it's hard to take back a "feature" that you never intended to give
out in the first place once people are using it.

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