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

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

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

[snip]

>
>> 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).
>
> All interesting ideas, but they're orthogonal to the question of my
> proposal.

True, I just got a little OT.

[snip]

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

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

>> - "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)?.

/ Johan