Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-10-05 07:35:31


Matt, I'm moving this to jamboost, as you did not object to that.

Background for the list: the essence of this email is how to prevent some/all
properties from appearing in target path, in case the properties are not
relevant for the target -- for example, toolset and optimisation have no
effect on PDF that BoostBook produce.

> > Should you decide to upgdate, please replace [ CALLER_MODULE ] in foo.jam
> > with
> > [ project.current ] and [ GLOB . : .... ] in Jamfile with [ glob ...... ]
>
> I am using the latest version of bbv2 (milestone 9.1). It's just that I get
> a lot of my code from the tools and build directories, and there are a
> couple occurences of e.g. caller_module. But I will change that.

In the current version we're using 'project.current' because it's much more
robust. For example, if 'exe' uses [ CALLER_MODULE ] to determine the
project, then you can't write a wrapper rule in project-root.jam which calls
'exe' -- because the caller will be project-root, not any Jamfile.

> > You recursively call 'do_main' and never stop recursion. The stack
> > overflows
> > and bjam crashes. Why do you make recursive calls in all actions?
>
> Yes, that fixed the problem. This is because I thought I could have the
> rule and the action share the same name, as in gcc.jam for example.

You definitely can! But you don't need to call the action from the rule. In
your case, you should be able to define just the action.

> > Why do you want that? Are you worried by long directory names, or there's
> > some
> > other problem.
>
> I'm not worried by directory names. I can always use a stage rule to move
> my targets around later. I just think it's superfluous. I see boost build
> as more than a compile / link, and therefore shouldn't be tied to a
> particular aspect (in that case compilation). But that's my personal view.

There are other cases where it's desired. For example, when using parser
generators it's good to place the generated sources under version control.
But it's not possible to place copies for all
debug/threading/optimization/toolset combinations. So, the generated sources
must be put just in "bin", without other directories.

> And yes, I'd be happy to work on it.

Excellent! The approach I consider reasonable is to introduce new
<relevant-feature> feature. It will be free (any values allowed), and can be
used in two ways

exe foo : foo.cpp : <relevant-feature>none ;

in which case V2 decides that no features affects the produces targets
and does not generate "gcc/debug/...." path elements.

exe foo : foo.cpp : <relevant-feature>foo <relevant-feature>bar ;

in which case only <foo> and <bar> will be considered relevant and show
up in the path. Since you define your own feature, you'd need to make it
relevant.

The implementation involves two parts:

1. Declaring the feature (in builtins.jam)

feature relevant-feature : : free ;

2. Modifying the constructor of the 'action' class (in virtual-target.jam).
The constructor should get values of <relevant-feature> in the passed
property set (using the 'get' method, see property-set.jam). If some
values are specified, it can either use empty property set (if "none" is
the value) or get the raw list of properties (with .raw method), filter it
with property.select and create a new property set with
property-set.create.

This means that V2 will still work with the complete set of properties, but
when the final dependency graph is created, the irrelevant properties will be
removed.

Does the above sound reasonable and is detailed enough for you to try
implementing?

There's another possible mechanism: instead of <relevant-feature> you can
write a custom generator which will remove the irrelevant properties before
creating the dependency graph. So, the irrelevant properties will be removed
in generator, not in constructor of 'action. But the list of properties will
be hardcoded in the generaotr.

The advantage of the approach I suggest is that property relevance depends on
user. For example, some users would like generated parsers to be placed in
the same directory as object files, and in some cases they should be placed
just in "bin". Using feature allows both uses, while with generator the
decision will be hardcoded.

If for some cases, the decision must be hardcoded, it's still possible to
create specific generator or main target rule which will add
'relevant-property' automatically. In your case, this can be done in the
'process_xml' rule.

Comments are most welcome!

- Volodya

 


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