From: David Abrahams (dave_at_[hidden])
Date: 2007-04-17 06:17:14
on Tue Apr 17 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com> wrote:
> 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.
That's the only perspective that matters to me (modulo
> - "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
Except that in the case of two alternatives, defaults currently *do*
come into play even if something else is specified.
lib c : c1.cpp : <debug-symbols>off ;
lib c : c2.cpp : <debug-symbols>on <profiling>on ;
will cause an error because <profiling>off (the default) gets combined
with <debug-symbols>on from the command-line to produce a build
request that matches nothing.
My point here is that producing an error in this case is inconsistent
with the logic used when there's only one alternative.
> 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
All interesting ideas, but they're orthogonal to the question of my
> 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
No; my point was only to say that my proposal is consistent with a
principle already expressed by the current semantics.
> - "Example 3": Agreed.
> - "Example 4": I honestly don't really follow this one. Haven't got time to
> read the original thread either, sorry.
Let me try to simplify it:
# configure the default installation of python, which is version 2.3
using python : 2.3 : /usr : : ;
# configure a specific python 2.4 installation for use with gcc-3.4.5_linux
using python : 2.4 : /usr/local/python/2.4/gcc-3.4.4 : : : <toolset>gcc-3.4.5_linux ;
The current behavior is to use the first installation of python,
* there is a feature, "<python>," representing the python version
* its default value is "2.3"
* that default (<python>2.3) is treated by Boost.Build as being just
as significant as the explicitly-requested
> - "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?
I don't understand. Example, please?
> 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.
Sounds complicated. Is it driven by a real use-case?
> - "Not a pure extension": As for 1), the answer is 'no'. I like your
> approach here.
Good, because I don't particularly want to implement the optional
extension. It's a bit messy.
> - "Optional extension to this proposal":
> Why not use the same syntax as is already used when setting conditional
> properties (less the resulting property):
We currently have two different syntaxes used for combining properties
in different contexts (using ',' or '/'). I don't have an opinion
about which one is better, but we should probably try to settle on
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
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