Re: [Boost-build] ** Need input on alternative selection **

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-04-17 03:40:53

Dave,

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
> opinions.
>
> You can read my proposal at
> http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection

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.
debug-symbols=on optimization=off.

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
sense, though.

- "Not a pure extension": As for 1), the answer is 'no'. I like your
approach here.

- "Optional extension to this proposal":

Why not use the same syntax as is already used when setting conditional
properties (less the resulting property):

<optimization>off,<debug-symbols>on

/ Johan