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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-04-17 03:53:36

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

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. That might be plausible, but I think it would
be wrong to apply this proposal just to requirements, without required 'when'.

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

3. For Example 2, I'd like to point out that in case of single alternative,
the problem of alternative selection does not exist. I don't really see
why any mechanism for alternative selection should overload the
"requirements" argument to mean something additional.

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.

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

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.

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. 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. 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.
And for the record, I think that the above case should always
be ambiguous.

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.

- Volodya