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

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

on Fri Apr 20 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com> wrote:

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

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
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com