Re: [jamboost] Re: How to suppress toolset in target paths?

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-28 11:42:00

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. 

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

If a simpler solution will work, that will be great.

> >> #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*".

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

- Volodya