[Boost-build] Suppressing auto-detected address-model from paths

Subject: [Boost-build] Suppressing auto-detected address-model from paths
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-04-03 15:48:38

Hi,

since recently, Boost's root Jamfile autodetects address model (as well as architecture). That's nice
for libraries that need to know address model in all cases, but it also adds an extra element to
target paths in all cases.

I was thinking about best way to avoid it. Conceptually, we have a number of toolset instances -
combinations of toolset name and exact commands, and for each such toolset instance, we can determine
default address-model. Then, if we have a property set which address-model property equal to toolset instance
default, we don't need it in path. That maps fairly clearly to features:

- Introduce toolset-instance feature that is always set, to some opaque identifier
- Make it composite, and include appropriate address-model= among the components.

That would suppress unnecessary address-model elements due to way we handle composite features already.
The only slight issues is that toolset-instance property - it would be actually nice to give ids
to each 'using', and make sure we always pick one of those, but it's a bit of work. While I have
some code for that in Python version, it works only for gcc and rather lightly tested.

So the attached patch implements a stop-gap approach. It adds a new composite property
representing deduced address model as well as 'hidden' attribute for features. So, if we have

        <deduced-address-model>64 <address-model>64

then the latter is consumed by the former, and the former is hidden from the path. If we have

        <deduced-address-model>64 <address-model>32

which would only be possible if some target specifically specify 32-bit, then we'd hide the former
property, while the latter will be visible.

The same approach should work for architecture. Comments? Is it good for upcoming release?

-- 
Vladimir Prus
http://vladimirprus.com