From: Zbynek Winkler (zw-bjam_at_[hidden])
Date: 2006-04-07 07:03:39
Vladimir Prus wrote:
>This is a call for help. At the moment, V2 (just like V1) tends to produce
>pretty long target paths. This issue has several components:
> 1. We produce extra path element even for features not affecting particular
> target. For example "debug" in target path for generated docs is wrong.
> 2. Using full names of features makes for pretty long paths, and there's no
> "compression" of paths.
> 3. The algorithm to compute the path is completely non-customizable.
>Those are problems, but really, I don't have completely answers to help. If
>somebody could come and propose/design the right semantic of target paths,
>this would be a great help.
>If you don't have time to design it all, but have some ideas, please speak
>out. Note, especially, that you don't need to have any deep knowledge of V2
>*code*, you just need to think about the best user interface, so it's a good
>way to affect V2 without learning jam language ;-)
For (1) I think the generator should be given a chance to decide which
properties make sense for the target being built. Thus generating pdf
from tex wouldn't have to end up in debug directory but a C compiler
would respect it.
For (2) and (3) I would suggest enhancing the build-dir property (or
something similar) to allow the user to supply a list of properties and
the corresponding directory. My list of used features for particular
project do not change that often, so this solution (adding a mapping)
would be quite sufficient.
-- http://robotika.cz/ Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic
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