Relevant properties (Was: bjam segfault)

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