Re: [Boost-build] Suppressing auto-detected address-model from paths

Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-04-06 22:25:15

AMDG

On 04/06/2015 05:01 PM, Robert Ramey wrote:
> Steven Watanabe-4 wrote
>> This doesn't take into account the fact that
>> fixing one such problem can exacerbate other
>> problems.
> 
> LOL - sure it does.  The objective is "Kaizan" - continuous improvement.
> Obviously fixing one problem to create another doesn't qualify. 
> 

Would you mind explaining how to create
automated regression tests for ease of use
and lack of surprises?

>>> There are well known sources of surprising behavior.  "global variable"
>>> like in user-config,
>>
>> What surprising behavior is caused by
>> the fact that user-config.jam is global?
> 
> Not that user-config.jam is global, but that it alters global settings such
> as compiler switches.  I understand the apeal of doing this and if you have
> to do it, you should not make it "silent" as it is now.  It should some how
> report these so that if the change when I'm not looking, I get a heads up.
> 

Are you going to read these messages
every time you run b2?  I'm not
denying that this information is
occasionally useful, but I'm far from
convinced that it's important enough
to be worth printing automatically on
every run.

> <snip>
> 
>>> side effects like when I set one feature it "knows"
>>> that some other feature needs to be set.
>>
>> I don't know what you're talking about.
>> In fact, I've heard a lot more complaints,
>> that Boost.Build /doesn't/ set features,
>> which "obviously" ought to be set automatically.
> 
> I'm sure you have.  I'm arguing that these suggestions are mis-guided
> and the attempts to implement this point of view make the program
> harder to use and easier to mis-use.
> 

I really have no idea where you're coming
from here, as your statements are too general.
In the case of architecture/address-model,
which has been one of the main instances
of this, I don't consider setting them
automatically to be wrong.
a) If the user sets them explicitly, this
   setting must be respected.
b) If they are not set, then they will be
   be set to match the compiler's default.

>From the point of view of someone running
b2, this automatic setting makes no difference.
It's impossible to build a program for an
unspecified architecture, so the only result
of leaving these features unset is that the
compiler makes the choice, instead.

For someone writing a jamfile, on the other
hand, the difference is clearly positive.
Before, architecture may or may not be present,
and could not be used reliably to change
the implementation.  (e.g. choosing the
right assembler file for Boost.Context).

> <snip>
> well, on my machine if I invoke b2 from the directory
> boost_root/libs/serialization/test I get build and run of the tests of the 
> serialization library (after building it's pre-requesites)  While if I run
> it from boost
> root I get something quite different - all the libraries built.  And this is
> with
> exactly the same command line !  So the current directory has a lot to do
> with what's going to happen when you invoke b2.

I didn't even consider that this might be
what you were referring to.  Using the
build script in the current directory is
pretty much standard practice for all build
systems starting with make.  I really don't
see how printing the cwd is useful to anyone.
Even if you ran
$ b2 .
or
$ b2 libs/serialization/test
it would still be affected by the current
working directory.

>  If the current directory
> doesn't have a jamfile.v2 , It seems its going to search the directory
> hierarchy
> using some rule that I forget.

It doesn't.  It issues an immediate error
if there's no jamfile in the current directory.

>  Any it's more behavior which one
> can't anticipate with spending a lot of time investigating before
> he actually launches the command.
> <snip>
>>> "GCC toolset doesn't work on MACOS - try using darwin instead"
>>> and have b2 abort.  
>>
>> I'm somewhat hesitant to suggest fixes in error message.
> 
> LOL - give me a break - it's an example off the top of my head
> 
>> - If we can be certain that the fix is correct,
>>   then there's surely a way to make sure that
>>   the problem can't happen in the first place.
> 
> THIS is the fundamental mistake !!!   In many or most cases I'm talking
> about there is no way you can automatically fix it because you have no
> way of reading my mind.  <snip>
> 

Which naturally lands us on the other
horn of the dilemma:

>> - If the suggestion is not what the user intends,
>>   it's going to cause even more confusion.
> 

And the worst part is:
- If we just say what's wrong without a fix,
  (possibly even if we do) it will almost
  certainly get chalked up as another
  incomprehensible b2 error.

I know that we need better error handling, but
it's not going to magically solve all our troubles.
Writing good error messages ranges from hard to
impossible.

In Christ,
Steven Watanabe