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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-04-17 14:54:02

On Tuesday 17 April 2007 13:55, David Abrahams wrote:

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

You seem to address this from formal standpoint, where any construct
in any language with some kind of semantics is clear. Somehow, it
often happens that user intentions while writing some C++ code does
not correspond to what semantic the written code has. 

Here with Boost.Build, we're fortunately don't have international standard
set in stone. So, given a certain combination of letters it's quite reasonable
to ask if it's obvious what the user wants here. If it's obvious, or one
possible interpretation is much more likely to be meant, we can use it. I
don't see such obvious interpretation here.

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

Maybe; let's assume I did not wrote the above.

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

We're trying to define syntax and semantics of alternative selection
from ground zero. You write down some code snippet, and ask
why it should not behave your 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.

Which rationale is that? I personally thing that there should be
no difference between specifying a default value of some feature
on the command line and not specifying it at all. If 

        bjam

and

        bjam toolset=gcc variant=debug threading=single

starts to be behave differenly, it's gonna be rather confusing. And note
that user might write

        bjam variant=debug,release

to build both debug and release variant. Should the debug build be different
from one from

        bjam

?

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

I don't want to discuss current definition, since I've proposed
the change current syntax -- using that, we'll have either:

        lib a : a.cpp : when <debug-symbols>off ;                  
        lib a : a-dbg.cpp : when <debug-symbols>on <profiling>on ;

in which case it's pretty much clear the second alternative should
be selected only <debug-symbols>on and <profiling>on is in properties,
or

        lib a : a.cpp : when <debug-symbols>off ;                  
        lib a : a-dbg.cpp : <profiling>on : when <debug-symbols>on ;

in which case <profiling> does not even come to play. Which of those cases
seem wrong to you?

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

Which does not mean it's a good thing.

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

Sorry, I don't understand what you say there.

> It isn't a coincidence that you chose that behavior when you designed
> the target alternatives feature.  

You're right, that isn't a coincidence. That's a mistake.

> As my proposal says, "one usually 
> wants a target to be built with properties that correspond to what the
> user explicitly requested"

I don't understand this phrase. What does "correspond" mean,
and what is "usually" and what is "explicitly requested".

> > 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'm not exactly sure why user interface for complicated combinations of
python versions should be simple.

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

So, we'll build a binary that will helpfully crash at runtime, despite the 
fact that second python explicitly says about specific gcc version.

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

You've made an arbitrary rule -- that more matched requirements are better.
That's an easy to implement rule. Does it correspond to any user expectations?
The property sets don't have a single common property -- so it's like
comparing apples and oranges using their weight only.

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

That if you proposal is implemented, the selection of alternative 
will depends on whether I say "toolset=gcc", "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.  
> 
> Why is that any more fragile than overload selection based on
> explicitly specified arguments (and not the default arguments)? 

Why are you trying to use C++ as model? C++ overloading is 
complex and many programmers don't know them. Is that an
example to follow? 

> And 
> what are the bad consequences you forsee?

I've explained above that some command lines that produce equivalent
results now can produce different results under your proposal.
 
> > And for the record, I think that the above
> > case should always be ambiguous.
> 
> Clearly.  But why?  Why is generating an error more useful?

Than picking an arbitrary alternative?

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

So I should ignore this formula, and this section?

- Volodya