Re: How to suppress toolset in target paths?

From: David Abrahams (dave_at_[hidden])
Date: 2004-12-29 11:16:57

Vladimir Prus wrote:
> On Tuesday 28 December 2004 17:54, David Abrahams wrote:
> 
>> >> 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?
> 
> To describe which targets are removed by --clean, you also need to describe 
> how target paths are generated, which can be hard. If you say that "target 
> paths are computed by Boost.Build", then user has no way to tell what targets 
> are removed. 

No, you don't need to describe how target paths are generated. The user
doesn't care where targets go; she either wants to remove everything,
or everything associated with specific targets. The only question in
the latter case is whether you want to want to remove files even if they
might be associated with other targets than those specified. So you
provide an option like "--gentle" in the case where you don't, or
"--scour" in the case where you do (depending on which you choose as a
default). For anything more detailed, the user can run bjam -n -a and
look at the output, or if even one person complains that it's too
laborious, we can add a feature that generates a "clean script" for her
that she can edit by hand to clean up only the files she wants.

>> > 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).
> 
> If a simpler solution will work, that will be great.

It will. You have to have some faith that users don't really need every
possible option. Jurgen didn't complain that he couldn't control what's
in the target paths -- he complained that he couldn't control what got
cleaned up. <in-path>all is too big a hammer, and it requires a special
case.

>> >> #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?
> 
> What do you mean? I imagined that each rule (like gcc.compile) will be 
> associated with a list of relevant properties (computed from toolset.flag 
> invocations). Since toolset.flags is called during toolset initialization, I 
> don't know what you mean by "executing the flags rule for *targets*".

Sorry, that was a v1-ism. Let me try again.
The method used by the flags rule to set feature relevance ought to be a
special case of a more general mechanism. That more general mechanism
ought to allow us to register a rule that detects when a target depends
on Python and makes python-version a relevant feature.

Now that I think of it, it seems reasonable to me that the one mechanism
for making a feature f relevant to a target is to add <in-path>f to the
target's build properties. So if you do it that way, I have no problem
with <in-path>.

>> >> 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 ;-).
> 
> I've tried ;-) For example, large part testing.jam is copied from v1. But when 
> we started V2 much of V1 codebase was almost unintelligible for me. 

What goes around comes around, as they say ;-)
We have to fix that problem (maybe not for you, but for me and
"everbody" else this time) -- and make sure it stays fixed -- in
whatever codebase we have.

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