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

From: David Abrahams (dave_at_[hidden])
Date: 2007-04-17 21:32:26

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

> On Tuesday 17 April 2007 13:55, David Abrahams wrote:
>
> So, given a certain combination of letters it's quite reasonable
> to ask if it's obvious what the user wants here. 

Sure, we can ask that about *any* Jamfile.  I do not accept at face
value the statement that the user's intentions are unclear in a
particular case.

I can only imagine one reason that one would say "the user's
intentions are unclear" given a particular piece of code: the code
would be a pretty good representation for semantics that the user is
likely to want, if only the semantics were different than they are
today... and that's all I'm saying.

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

IMO people can be trusted to express what they intend as long as we
make it relatively easy to express the most common cases.

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

*I* wasn't starting from ground zero.  We have a reasonably large
collection of use cases, and we have existing semantics which I was
assuming we'd want to not disturb too much.

> You write down some code snippet, and ask why it should not behave
> your way?

Yes.

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

For one thing, the person forming the build request -- the author of
dependency targets and ultimately, the author of the command-line --
has a better idea of what's desired than the person who defined the
features (and therefore determined their defaults)!

Moreover I think the general principle that explicitly-specified
things get more weight than implicitly-specified ones is fundamental,
and resides "in the bones" of most programmers.  If we continue to
survey users we will find more and more of them naturally make that
assumption.

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

Not to me.

The difference above is only confusing if:

a. the user is able to keep track of the default value for all
   features.  I claim that it is effectively impossible -- I certainly
   can't do it -- especially so because many configuration operations
   (such as those used by python and gcc -- see "flavour") create
   features that, in common cases, the user won't know or care about,
   AND

b. the user expects defaults specified by the person who designed a
   feature to be given as much weight as the user's own explicit
   requests!

I claim that the likelihood of b. is vanishingly small, and when taken
together with a., it's effectively zero.

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

That's certainly reasonable, especially if the target has a
default-build setting.

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

If you're unwilling to discuss that, I should just give up.
In my opinion, that question is at the heart of the matter.

Please tell me whether you're willing to discuss it.  If not the
consequences for me are fairly serious.

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

Both of them.  I need to express that a single target alternative will
effectively be chosen for any of the following build requests:

  bjam debug-symbols=on
  bjam profiling=on
  bjam profiling=on debug-symbols=on

and that a different one will be chosen for

  bjam debug-symbols=off

I claim that is a more common need than expressing that one
alternative will be chosen *only* when all of a particular set of
features are explicitly requested and/or arise as defaults.  You
probably have to consider prebuilt library targets, which I notice
none of your examples use, in order to see why that's the case.

I also claim that in the cases where the system causes an error, the
user would be better served by my semantics.

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

But it _is_ a good thing.  Your original instincts weren't wrong; they
just weren't followed to their logical conclusion.

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

Hmm, I don't know how to say it better.  Today, the only alternative
selection mechanism is based on requirements, and everything works out
fine in the vast majority of cases as long as the user's explicit
build request lines up *exactly* with the target requirements for a
particular alternative.

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

"Correspond to" means "are the same as," with provision for
requirements known to the target author to override that.

For the meaning of "usually" I refer you to a dictionary.  I mean it
in the, um, usual sense.

I gave a definition for "explictly requested" in my proposal.  At the
most fundamental level it means what the user asks for on the
command-line.  The author of a dependent target also makes an explicit
request for particular properties when he states that target's
requirements or specifies explicit properties for a dependency target.

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

The simple answer is "because simpler user interfaces are easier to
use."  Why on earth would I want it to be complicated if it could be
simple?

More speicifically, when requesting a particular build, one generally
cares about specific properties of the python one is using (the ones
one will explicitly request), and not about other properties.  For
example, I want to make sure that my code works with python-2.5.  I
don't particularly care that my one installation of python-2.5 happens
to have python debugging or profiling enabled or debug symbols off;
building with that version is a valid test of whether my code works
with python 2.5.  Asking me to remember all those other properties
when requesting a build against Python 2.5 is needlessly difficult.

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

?? Why do you say that?

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

Except I claim it's not arbitrary.

> That's an easy to implement rule. Does it correspond to any user
> expectations?  

Most of the time.

> The property sets don't have a single common property -- so it's
> like comparing apples and oranges using their weight only.

I don't think that's a helpful analogy.

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

[Well, don't forget that my proposal specifies "toolset" as a special
case which is always considered explicit.  But that aside, ]

Yes.  So?  That doesn't address what you "don't think" above.

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

Because it provides a useful analogy.

> C++ overloading is complex and many programmers don't know them. Is
> that an example to follow?

Yes, because it turns out to be highly usable despite the fact that
most programmers don't know the exact rules.  Anyway, the rule I
propose is much simpler even than the one you are proposing, so I
don't think the "complexity of rules" is at issue here.

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

Yes, I know.  That's why I acknowledged that it's "not a pure
extension."  The fact that it's not perfectly backward-compatible
doesn't make it a bad idea.  As you say, we don't have an
international standard to uphold (yet).

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

It's *not arbitrary*!  There's a well-defined and simple rule that
generates useful results!

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

Unless you think it's important to be able to write something that has
exactly the current semantics for all build requests, you can ignore
it.  It doesn't seem that Felipe thinks the current semantics are
worth keeping.

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