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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-28 02:48:44

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.

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

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.

>
> #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). 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. I though that it would be handled by adding 
<in-path>python-version to requirements of all extensions.

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

- Volodya