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

Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-04-06 19:01:41

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. 

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

I may set some compiler switches in user-config and forget that I did so.
Or I might change my environment, or run a different compiler as a test.
The functioning of b2 (BTW and lots of other programs) may change 
with me having idea what the source of the change is.  Its exactly
analogous to the problem of global variables in a C++ program -
and creates the exact same type of problems.

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

>>  Default behavior like naming
>> of output libraries - which is done silently.
> 
> This isn't Boost.Build per se.
> Library naming is controlled
> by Boost's top-level Jamroot.

My mistake, I thought the library name and location was determined by
the toolset, auto link variables, stage and other command line switches
in the b2 command line (BTW which is right place so this works for me).

>>  One giant global variable
>> whose
>> effect is not transparent is the current directory from which b2 is
>> invoked.
> 
> The only place I know of where the
> current working directory matters is
> for building documentation.  I consider
> this a bug in doc toolchain.

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.  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.  Any it's more behavior which one
can't anticipate with spending a lot of time investigating before
he actually launches the command.

> <
>> These "environments" should be listed when b2 starts unless a -q switch
>> is included.
>> 
> It can't be -q, because -q already means something else.

LOL - pick another switch then.

> I'm very reluctant to make the output more verbose
> by default.  I see plenty of issues where I can
> make the problem completely obvious, simply by
> trimming the error message.
> 
>> "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.  If I say "b2" you can't decide for me without
asking what I want.  If I go to 31 flavors icecream as ask for an
icecream cone - what's going to happen? Is the guy going to just
take a look at me say - that guy is 67 years old - they usually order
pistachio so that's what I'll assume he want's.  NOOO he's going to
ask "what flavor" and abort the operation until I try again.

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

The above is an example.  If you can think of something better fine.  The
point is that the current situation costs a naive user such as myself
a lot of time and frustration.  If you can find a way to diminish this b2
will be more widely appreciated and used.

>>  I'm guessing that 
>> the just tweaking the gcc and/or darwin toolset would do the job. 
>> That one simple change would quash this particular problem
>> forever.
> 
> It would help some, but I don't agree that it would
> eliminate the problem entirely.

And??? what's wrong with making an improvement?

>  I don't believe that
> there should be a darwin toolset in the first place.

An even better fix !!! - You're getting it !!!

> Also, this particular problem hasn't been hasn't been
> nearly as much of an issue since the default toolset was
> fixed to be darwin.  I do agree that there should
> be better checking when initializing a toolset.

Note that I'm not complaining about this or that particular issue
but the whole way of looking at what the task is.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Suppressing-auto-detected-address-model-from-paths-tp4674095p4674217.html
Sent from the Boost - Build mailing list archive at Nabble.com.