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

From: David Abrahams (dave_at_[hidden])
Date: 2007-04-17 05:55:55

on Tue Apr 17 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:

> On Sunday 15 April 2007 16:42, 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
>
> I have a number of issues with that proposal:
>
> 1. Generally, if we have a case where user intentions are not clear,

I disagree fundamentally, as written in my other message.  There's no
more reason to approach a Jamfile with the assumption that the user
intentions are unclear than there's a reason to presume that the user
intentions behind a set of valid C++ declarations are unclear.  The
language specifies semantics.

> I find it better to provide a way to express said intentions
> clearly, rather than introducing algorithm that produces the result
> expected by this specific user in this specific case.

Yes.  I believe that my proposal more clearly expresses
commonly-desired intentions than yours does.  In fact, I believe that
some commonly-desired intentions are extremely difficult to express
with your proposal.

> We talked off-list that Dave's proposal and mine can be both
> implemented, and then probably Dave's proposal can be used to rank
> alternatives with explicit 'when' clauses. 

Sorry, there must have been some miscommunication.  I don't remember
discussing that latter part.

> 2. In Example 1, my claim is the best alternative is not apparent.

As my proposal says, it depends on your definition of "best."  What
reason can you see for not defining "best" my way?  

My definition of "best" is not arbitrary; there's a sensible
rationale for valuing properties that are explicitly specified over
those that arise implicitly.

Why do you think that the current definition of "best" is more
sensible than mine?

> 3. For Example 2, I'd like to point out that in case of single
> alternative, the problem of alternative selection does not exist.

No, instead there's the problem of whether to select "this is an
error" or "make a plausible choice and proceed."  Currently the single
alternative case does the latter but the multiple alternative case
does the former.  From that point of view, it's inconsistent.

> I don't really see why any mechanism for alternative selection
> should overload the "requirements" argument to mean something
> additional.

It already does.  If the requirements of an alternative are an exact
match for the build request, the alternative is selected.

It isn't a coincidence that you chose that behavior when you designed
the target alternatives feature.  As my proposal says, "one usually
wants a target to be built with properties that correspond to what the
user explicitly requested"

> 4. For Example 3, I'd note that "intended result" should read
> "what the specific user wanted". There's no reason all users
> will want the same.

IMO real use cases should weigh more heavily than hypothetical ones.

> 5. For Example 4, I actually don't think that the situation
> (several gcc versions, two different python version, 
> some built for specific gcc version)
> is something so typical that adding python version explicitly to
> the command line is unacceptable.

When combined with a few other features, such as python debugging and
multithreading, command-lines start to become extremely cumbersome.
It's a usability problem.

> I also note that it seems that if python=2.4 is explicitly present
> on the command line, Dave's proposal will happily select the second
> python, no matter what version of gcc is being used -- which is wrong.

No, it's not wrong.  The user asked for a build with python 2.4, and
that is the only installation of python 2.4 available.

> 6. The same example 4 mentions how hard it was to debug some
> problem, which might suggest we need better debugging, but has no
> relation whatsoever to the best way to select an alternative.

Of course it does.  If we can make it a non-problem, it avoids the
problem of debugging.

>
> 7. "Details of proposed semantics". I don't really think that a tie between:
>
>      lib a : : <threading>single <link>shared ;
>
> and
>
>     lib a : : <debug-symbol>on ;
>
> should be resolved in favour of the first alternative because it matches
> more requirements. 

Clearly.  The question is, why not?

> I also don't think that given:
>
>    lib a : : <threading>single <link>shared ;
>
>    lib a : : <toolset>gcc ;
>
> The selection of alternative depends on whether I say "toolset=gcc",
> or "threading=single link=shared" on the command line. 

What it does today isn't a matter of opinion.  What are you really
trying to say?

> Now, if you don't specify a value for a feature on a command line,
> the effect is the same as if you specify the default
> value. Alternative selection that depends on explicitly specified
> properties seem fragile.  

Why is that any more fragile than overload selection based on
explicitly specified arguments (and not the default arguments)?  And
what are the bad consequences you forsee?

> And for the record, I think that the above
> case should always be ambiguous.

Clearly.  But why?  Why is generating an error more useful?

> 8. "Optional extension" section has a formula:
>
>         Sum( for all matching property paths p, 10^s(p) ) 
>
> I don't really understand the meaning of it, I don't understand why
> 10 raised in some power is good approximation for anything, nor
> do I think Jamfiles authors are supposed to understand this math.

It's not a good approximation for anything.  It's a fairly arbitrary
way of weighting in favor of "and requirements" with more components.
I'm not attached to that particular approach, and it's not clear at
all to me that it's needed.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com