From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-04-20 02:14:08
David Abrahams wrote:
> on Tue Apr 17 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com>
>> 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
>> 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 ;
> bjam debug-symbols=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.
Yes, but the original example didn't have multiple alternatives for lib c.
> My point here is that producing an error in this case is inconsistent
> with the logic used when there's only one alternative.
I never questioned that.
>> 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
True, I just got a little OT.
>> - "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 ;
> bjam 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
Ok, got it. I't just basically the same problem. FWIW, I'd also expect 2.4
to get selected due to the explicit request.
>> - "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?
prompt> bjam debug-symbols=on
project foo : requirements <debug-symbols>on ;
>> 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?
As I said - "off the top of my head". It would probably be complex to
implement. Also, I suppose that target requirements should be ranked higher
than project requirements. See previous comment about project requirements,
>> - "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
As the comma-separation is probably in wider use, perhaps that would be an
argument for it (if the proposal would be accepted)?.
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