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

From: David Abrahams (dave_at_[hidden])
Date: 2007-04-24 15:41:32

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

> On Tuesday 17 April 2007 13:34, David Abrahams wrote:
>> 
>> on Tue Apr 17 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
>> 
>> > consider this:
>> >
>> >    lib a : a_msvc.cpp : <toolset>msvc <link>static ;
>> >    lib a : a_gcc.cpp : <toolset>gcc ;
>> >
>> > What the user wants here? 
>> 
>> Presumably the user wants the semantics that the system implements for
>> this case, or he would have written something else.  
>
> In another email, I explain why using existing semantic to force
> intentions on user is not right.

No you don't; you simply state that it's not right based on some
abstract "principle."

Furthermore, I object to the way that's phrased -- it's emotionally
loaded and simply inaccurate.  Nobody is "forcing intentions on the
user."  The user intends whatever he intends.  The question is what
sort of intentions can be expressed economically and naturally in our
build description language.  My claims are that:

 1. the things that can currently be expressed economically and
    naturally don't line up well with common intentions

 2. we could make them align better with common intentions

 3. asking people to be more explicit about everything doesn't help
    with economy of expression

 4. the particular way you propose asking people to be explicit would
    make some common intentions *very* difficult and cumbersome to
    express.

>> > My opinion here is that it's bad design to have one syntactic
>> > element to be used both to affect selection of alternatives,
>> > and, once alternative is selected, to affect build properties.
>> 
>> It's only bad design if the two issues are unrelated, but they're not.
>> They're very commonly correlated, (as my proposal says, "one usually
>> wants a target to be built with properties that correspond to what the
>> user explicitly requested") and in fact the current design of
>> Boost.Build implicitly acknowledges that correlation -- just not as
>> fully as it could.
>
> As I said in another email, I don't understand your "one usually
> wants a target to be built with properties that correspond to what the
> user explicitly requested" and I don't know where that is acknowledged.

I tried to break it down for you in another email:

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

I don't know where that explanation is acknowledged.

>> > With equal success, we can try to merge default build, requirements
>> > and usage requirements in one parameter.
>> 
>> That would only be true if they are all strongly correlated.  But
>> they're not.
>
> Are you sure? I've heard several person ask if he can avoid specify <include>
> both in requirements and usage-requirements.

Yes, there are occasional matches (not even random ones), but the need
to have completely separate requirements and usage-requirements is
sufficiently common that there is no strong correlation between them.

>> > I believe the fundamental thing about alternative selection is it
>> > can fail.  For a trivial example, if we have alternatives for gcc
>> > and msvc, we don't want either to be silently selected when
>> > building with borland.
>> 
>> Why is that any worse than silently selecting a single target (with no
>> alternatives) whose requirements are <threading>multi when building
>> single-threaded?  That is the current behavior.
>
> Because alternatives are used when you can't use a single target, for
> whatever reason. If gcc alternative and msvc alternative are needed,
> you probably don't want gcc alternative to be used when building with
> msvc -- supposedly because it won't compile. 

You must mean "link" or "run" or something else.

> Then, even less want gcc alternative to be used with a random
> compiler.

That's true in some cases, just as it's true that you apparently don't
want to link together single- and multi-threaded targets built with
MSVC... which can just as easily happen today with a single
alternative.  In other words,

  ** This potential problem is not a property of multiple-alternative **
  ** targets. It applies equally to single-alternative targets.       **

Therefore, 

  ** We should not use the multiple-alternative-ness to determine **
  ** whether it's going to cause an error.                        **

Your instincts to decouple things is right, but you're aiming at a
coupling that doesn't solve the problem.  You've got
multiple-alternative-ness bound to the prevention of link
incompatibility, which should instead be handled by some kind of
explicit link compatibility attribute, which represents the true
nature of the issue.

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