Some 'stage' changes

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-01-21 11:08:13

Some time ago we've discussed how best to apply naming conversion to target 
names, such as 'd' letters for debug builds. I've committed some changes 
resulted from that discussion.

Here is the summary of changes:

Any custom naming convention will applied at the time targets are built.
The 'stage' rule won't allow to rename targets (at least yet). 

We will drop the current meaning of the <tag> rule -- when the value is
added to the 'basename' of the target name, because what happens when two
values for <tag> is specified is unclear.

The <tag> feature now must be present only once in build properties, and
its value must the have the form '@rule.name'. The mentioned rule
will be called to compute the name of each created virtual target that has
<tag> in properties.

The rule should match this prototype:

rule name ( name : type ? : property-set )

The 'name' parameter is the suffix-less target name that Boost.Build has
computed. The 'type' parameter is the target type. The 'property-set' parater 
is the set of properties used for building this target.

If the rule returns a non-empty string, that one is used as the target
name. Otherwise, Boost.Build will take 'name' and append suffix appropriate to
the type/property-set combination. 

Note: maybe in future, we'll want the 'stage' rule to support the <tag>
feature. Then it will be possible that <tag> is feature is present both
when building a target (say, 'exe') and when staging it. How the rules
mentioned in both cases interact is up to the user. In particular, if
the rule is the same and adds some element to basename, then it will
be added twice.

Things left to do: 
- rename 'stage' to 'install'
- implement proper versioning support for dynamic libraries

If there are any problems with my changes, let me know.

- Volodya