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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk