Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2007-04-23 04:57:56

on Fri Apr 20 2007, "Johan Nilsson" <> wrote:

> David Abrahams wrote:
>> on Tue Apr 17 2007, "Johan Nilsson" <>
>> wrote:
>>> 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
>>> 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
>> implementability).
>>> - "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.
>> 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.

Right. I don't think we're arguing about anything significant here.
You're saying that building lib c as described in the one alternative
case makes sense; I'm saying I agree, but it's only consistent if you
believe that the current logic for refusing to build, in the case with
two alternatives, is nonsense. Apparently we both agree on that too.

>>> - "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,
>> because:
>> * 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
>> <toolset>gcc-3.4.5_linux.
> Ok, got it. I't just basically the same problem.

Exactly; it's just a different example of how the same problem arises.

> FWIW, I'd also expect 2.4 to get selected due to the explicit
> request.

Right; me too.

>>> - "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 ;
> +
> prompt> bjam

Sorry, I still can't understand what that is supposed to mean. What
are "~=" and "+" doing there?

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

I don't believe that it's appropriate to add complexity without real
use cases (and sufficiently important ones) to justify it.

>>> - "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
>> 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
>> one.
> As the comma-separation is probably in wider use, perhaps that would be an
> argument for it (if the proposal would be accepted)?.

Like I said, I don't really have an opinion.

Dave Abrahams
Boost Consulting
Don't Miss BoostCon 2007! ==>

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at