What am I trying to do? Well, I probably have more complicated than normal install requirements due to the application having to build with different toolsets on the same build host. I want the install destination directory to be a product of toolset, toolset release, variant, subproject, object type, etc., determined dynamically by a <conditional>rule.

To effect this capability with the current stage.install rule:

rule install ( name : sources * : requirements * : default-build * )

I have to jump some hoops as follows with a my-install wrapper (for stage.install) rule and a my-locator class:

rule my-install ( sources * )

1. Create a unique dummy install name argument for stage.install
2. Create a new instance of my-locator class ==> locator
3. stage.install $(dummy-name) : $(sources) : <conditional>@$(locator).locate ;

(In reality, I have more than one wrapper rules, my-install-x, my-install-y, ..., which handle different types of install targets (libraries, executables, source, etc.) that require different install locations.)

The locate rule of class my-locator computes the destination install directory and adds <location>$(destination) to the property set if not already present.

Why do I need class my-locator? Because if I just have a static my-locator rule outside of a class, it does not get re-invoked for every my-install-* invocation. It behaves like there's a global dictionary of <conditional>rules each of which is expected to yield a set of properties that are not expected to change when used in different contexts. Having a new my-locator instance for each my-install-* invocation works around this limitation.

It would have saved me a lot of work if stage.install were as follows:

1. optional name argument if <conditional>@rule is given - install could compute a dummy name if one is required internally.
2. <conditional>@rule re-invoked for every context in which it is specified as a requirement. Don't know how cosmic such a change would be for the current design.

At any rate, I'm happy to have found a solution. Thanks for the follow-up.

Cheers,
Mark

Vladimir Prus <ghost@cs.msu.su> wrote:

Hi Mark,
the above behaviours is at least by design. Two main targets with the same
name are considered to be alternatives of the same target, and Boost.Build
tries to select one of them, which is not possible in the case above.

Can you tell what are you trying to do?

- Volodya