Re: How to suppress toolset in target paths?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-28 09:54:06

Vladimir Prus wrote:
> On Monday 27 December 2004 19:58, David Abrahams wrote:
> 
>> > 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. 
> 
> I'm worried that this solution is not so simple to explain and implelement.

I think it's pretty simple to explain (and I'm guessing, to implement as
well). I know I could document it cogently in about 3 minutes. What
confusion do you anticipate?

>> > 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.
> 
> By saying <in-path>all you'll be back to the current behaviour, where parser.h 
> is generated into bin/debug/gcc and bin/release/gcc, so the problem is gone.

That seems to me like a way of solving one problem by creating two more
(too-long target paths and targets being rebuilt needlessly).

>> #2, I don't see a need for <in-path>, and it adds complication. 
> 
> I think I do. Consider Boost.Python. One day V2 will have python-version 
> feature. It should be present in target path of object files when building 
> Python extension (at least I think so). 

Yes, at least when more than one version is registered with "using."

> But it's better not be present when 
> building ordinary libraries. So, the 'python-version' feature cannot be 
> considered relevant to all object files, it is relevant to object files which 
> are used when building extension. 

Good so far.

> I though that it would be handled by adding 
> <in-path>python-version to requirements of all extensions.

Why not handle it by only executing the flags rule for targets that need it?

>> 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.
> 
> I agree and aware of this. In fact, the "relevant features" issue is in 
> tracker for very long time for exactly this reason -- I waited till the need 
> arises.

Well at the same time I think you should not be afraid to take what
works from v1 ;-).

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