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 13:52:31

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

There are well known sources of surprising behavior.  "global variable"
like in user-config, side effects like when I set one feature it "knows"
that some other feature needs to be set.  Default behavior like naming
of output libraries - which is done silently.  One giant global variable
whose
effect is not transparent is the current directory from which b2 is invoked.
These "environments" should be listed when b2 starts unless a -q switch
is included.

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.  

This wouldn't entail fiddling with b2 source code.  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.

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.

Robert Ramey

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