From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-04-17 03:40:53
David Abrahams wrote:
> Volodya and I have been talking about how target alternatives work
> today in Boost.Build. We seem to agree that something is wrong with
> them, but that's about all. We have different opinions about what's
> most broken, and therefore different ideas what should be changed. We
> would appreciate if members of this list help us by expressing their
> You can read my proposal at
In brief, I believe your proposal makes sense. Intuitively, matches for
explicitly requested build properties should rank "higher" than matching
implicit/default properties. Some section-specific comments below. These are
from a user's perspective only.
- "Example 1": Makes sense.
- "Example 2": A bit more convoluted:
Building lib c as described makes sense. IMHO, there's not even a
contradiction here, as a default is something that only comes into play when
nothing else is specified. Here, 'profiling' is specified, so logically the
default shouldn't even be taken into account.
Building lib b isn't equally obvious to me; if explicitly requesting
debug-symbols=on and the library _requirements_ is to build with
debug-symbols=off, should the build just happily execute? Let's consider the
reasonable alternatives for this specific case:
a) lib b is not built at all. This is flagged as an error, and the build
stops if the '-q' flag is given at the command-line.
b) lib b is not built at all. This is considered normal, as a requirement
for building the library is <debug-symbols>off and the generation of debug
symbols is explicitly requested. If other targets depend on lib b, they will
cause the build to fail.
c) lib b is built anyway, but with debug-symbols=off (current behavior,
right). I have to agree that from a usability perspective this is the most
lenient way. For alternatives a) and b) above, it would otherwise complicate
things whenever I'd like build my own target depending on lib b with e.g.
So, I guess the current behavior is fine, but I personally would like to
have a warning output when such a conflict is detected. Also, perhaps adding
a command-line option to the build system that would cause either a) or b)
to happen would be an interesting feature, e.g.
"bjam --property-matching=strict" (or whatever).
Just a comment on "requirements describe how a target must be built,
not exactly how it must be requested". Sure, as a general statement that
makes sense, but requiring a target to be built with "debug-symbols=off"
with a request for "debug-symbols=on" doesn't sound equally sane, does it
- "Example 3": Agreed.
- "Example 4": I honestly don't really follow this one. Haven't got time to
read the original thread either, sorry.
- "Details on proposed semantics":
Sounds reasonable, but what about requirements specified for the project at
a higher-level Jamfile? Shouldn't these also be considered explicit, or at
least higher ranked than the defaults? Just throwing out an idea off the top
of my head: What about ranking the properties from e.g. high-to-low:
explicit (command-line) => explicit (project requirements) => explicit
(target requirements) => implicit (default)? Don't know if that would make
- "Not a pure extension": As for 1), the answer is 'no'. I like your
- "Optional extension to this proposal":
Why not use the same syntax as is already used when setting conditional
properties (less the resulting property):
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