Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2015-04-06 17:18:54
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
> 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
> 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
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
> 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk