Re: [Boost-build] single threaded build with msvc-7.1?

From: David Abrahams (dave_at_[hidden])
Date: 2007-11-08 09:24:16

on Thu Nov 08 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:

>> Either you create straightforward rules for interpreting build
>> requests usefully with respect to target requirements, or you force
>> the user to be excruciatingly explicit in order to avoid hard errors
>> when you don't trust him to understand how build requests and target
>> requirements combine to produce real results.  Pick one principle and
>> stick to it.
>
> I think the current rules are quite straightforward.

In some cases, yes.  In others they force the user to be
excruciatingly explicit in order to avoid hard errors.

>> Rejecting the substance of
>> http://zigzag.cs.msu.su/boost.build/wiki/AlternativeSelection doesn't
>> make any sense unless you're going to take Deane's suggestion.
>
> What do you mean by "substance"? 

I mean it in this sense:

   "The most important element in any existence; the characteristic and
   essential components of anything; the main part; essential import;
   purport."

(http://www.brainyquote.com/words/su/substance225591.html)

> There are various ideas there, and the one that appears most
> relevant here is treating properties specified on command line
> differently from defaulted properties.  

No, the most relevant idea there is choosing semantic rules that give
useful results without forcing the user to be excruciatingly explicit
just to prove to you that she understands the results she's going to
get.

> And I think don't think that's a good idea.

Let me get this straight.  You insist:

* that the system should proceed without a hard error, when the user's
  explicit build request and a target's explicit requirements
  conflict, because even though the user *might* have intended to ask
  for something else, the result is useful.

* that even if all the explicitly-requested build properties can be
  matched by exactly one target alternative, the system must generate
  a hard error when defaults values chosen for some features that may
  be unknown to the user do not match that alternative, because even
  though building that target would be useful, the user *might* have
  intended to ask for something else.

?

It's no wonder people like Robert think the system is being too
"smart" for its own good.  No system can avoid the impression of being
completely capricious if it ignores what people explicitly request and
instead gives priority to rules that are often unknown to the user.

Remember, features (and thus their defaults) are introduced by the
authors of plugin toolsets, and target alternatives for prebuilt
libraries are specified by site administrators unaware of all the
toolsets and resulting features/defaults (indeed, some of those
toolsets may be installed later).  Both these people can be different
from the person invoking bjam, who has little knowledge of the details
of what those other two have done.  By making the interaction of
feature defaults and feature an important part of the semantics of
alternative selection, you put the poor user in an impossible
position, with hard errors that she has no way of diagnosing.

You could mitigate that by making the error messages better,
explaining how the defaults are interacting to make the user's life
miserable... but then, that would require acknowledging that the
properties specified on the command line need to be treated
differently from the defaulted properties, at least insofar as
diagnostics are concerned.  It wouldn't fix the underlying problem,
but at least one would feel like one was working with a capricious
system that was willing to explain the rules.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com