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 17:18:54

AMDG

On 04/06/2015 11:52 AM, Robert Ramey wrote:
> Steven Watanabe-4 wrote
>> Well, there's not much Boost.Build can do about this, is there?
> 
> I get from your response that you feel you've done all that is reasonable
> to do to make this easier for the rest of us.

In some cases, yes.  I can't think of anything
I can possibly change to alleviate the particular
complaint that I was responding to in any way.

>  And that if we're having 
> problems, we're just not working hard enough or need to be doing
> something differently.
> 
> I think you should approach these suggestions from a different view point.
> 
> Start with the premise that any build tool should be easy and obvious to
> use to get some desired result and hard to mis-use for the average
> person who can write a C++ program.  Anytime such a user has difficulty
> make the tool do what he wants it has to be considered as some type
> of program and/or design bug and should be addressed as such.  After
> addressing things this way, complaints will taper off exponentially.  That
> is the time between complaints will increase linearly.
> 
> Of course this seems impossible.  But it's not.
> 

This doesn't take into account the fact that
fixing one such problem can exacerbate other
problems.

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

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

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

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

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

> At this point, it's too hard to go back and redesign everything.  But what
> you can do is something like the following.
> 
> a) User has a complaint.  This takes the form like "I can't build with gcc
> on Mac OS - it gives me an error which I don't understand".
> 
> b) current method - respond to the user's complaint with "Try using
> toolset darwin rather than gcc".  Problem solved -  NOT.  It's not fixed
> it's just going to come up again.
> 
> c) The source of the problem is that the error message doesn't tell the 
> user what to do.  So he has to email in and to get a response.  The fix
> for this is to tweak something somewhere so that the error message
> says something like:
> 
> "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.
- 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.
- If the suggestion is not what the user intends,
  it's going to cause even more confusion.

> This wouldn't entail fiddling with b2 source code.

Very few things do.

>  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.  I don't believe that
there should be a darwin toolset in the first place.
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.

> Of course the above are examples and might not be exactly correct.
> But I think one could find his own.
> 
> So the problem isn't b2  - it works (or can be made to work).  It's
> not badly documented (thought I'm thinking some information on 
> toolsets is out of date).  It's that you're thinking since the above is
> true you're done.  That is not true.  I think you'd be more successful
> if you stepped backed and examined your criteria for success and 
> shifted it from having a correct, documented and useful software tool
> to a tool that moderately competent programmers can use with to get the
> results
> he desires without major frustration.
> 
> I pains me to see you guys working so hard and not having 
> your "customers" as happy as I think they should and can be.
> 

In Christ,
Steven Watanabe