From: Brian Braatz (brianb_at_[hidden])
Date: 2005-06-12 13:17:01
sorry for the disconnection in time.
Let me say a (HUGE) THANK YOU for writing up below, it really has my
gears turning. I have been reviewing your mail, and reviewing the boost
build docs contemplating the issues you raised daily since your post.
(thinking maybe if I "sleep on it" a solution will appear).
Where I am at:
* I see what you are saying
* I am left still feeling like this is a solvable problem
* Yes, you are right there is no clear and easy path that we can see
* Before I die (grin- I am on a mission :) ), I will do something to
enable debugging of build problems. There IS a solution, one just have
to think about it long enough until they find it :)
What I am thinking right now:
* I would appear to have more bjam\boost build problems than most people
* I need to be careful, because I have a tendency to try to do too many
things at once. (right now I am working to finish a preview of a
potential boost library).
* I need to remember that trying to think about this from the top down,
and "organically" growing a solution are two different things.
My plan (to address this organically):
* First off finish my other work :)
* then spend the time to really get my head wrapped around bjam\boost
* debug my own build problems- and make careful notes on "what the
* Post-Mortem- build a tool that WOULD have shown me the problem
immediately. I.e. (weak example:) if my bjam.exe is the wrong version-
then the tool would simply report the version
* share the tool with the rest of the community.
* watch the users list for folks having build problems- offer to help
them- use the tool as a proxy for figuring out their problems- in this
way the tool evolves the ability to solve the common problems. OR it
becomes clearly proven that this is not possible. (my gut tells me it IS
* I am going to save this mail off, and then when I have learned a few
things by doing above, I may "re-open" this thread with what I have
Thank you David for a very useful conversation. :)
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> On Behalf Of David Abrahams
> Sent: Monday, June 06, 2005 5:18 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Boost Build Env Checker (was RE: Re:
> CustomerFriendlier Boost Installation)
> "Brian Braatz" <brianb_at_[hidden]> writes:
> > boost-bounces_at_[hidden] wrote:
> >> On Behalf Of David Abrahams
> >> Sent: Tuesday, May 31, 2005 7:08 AM
> >> To: boost_at_[hidden]
> >> Subject: [boost] Re: Customer Friendlier Boost Installation
> >> "Brian Braatz" <brianb_at_[hidden]> writes:
> >> > HAVING said that here is the suggestion, reformed:
> >> >
> >> > Boostenvcheck.exe become s a program which LISTS the dependencies
> >> > your configuration.
> >> Can you show an example of what that output might look like? I
> >> have a clear idea of what you mean by "dependencies" or "your
> >> configuration."
> > [Brian Braatz Writes:]
> > I must say, I need to fully absorb how bjam \ boost.build
> > until doing so, please understand the details of this idea maybe ill
> > formed. I get it conceptually, but it is still a "black box" in my
> <snip example of non-Boost environment check>
> > when it says "passed"- I can quickly re-direct them back to their
> > if they are not convinced, I can have them send me the report and I
> > look at it and try to determine where the issue is.
> Well, let's look at the dependencies for Boost.
> 1. Boost.Build v2 (I'm ignoring v1 as we're going to retire it)
> A. Boost.Jam
> I. bjam in the PATH, or
> II. The contents of tools/build/jam_src available with which to
> build it. Should we check for every file? Just running the
> bjam build procedure does that by itself; does it make sense
> to build a redundant checker?
> B. The contents of tools/build/v2. Should we check for every file?
> C. Toolsets properly configured in user-config.jam and/or
> Default versions of these configuration files ship with
> Boost.Build and are used unless the user supplies her own
> versions, so there's nothing to check for. Boost.Build
> itself is designed to detect when there are no toolsets
> configured or when toolsets are configured improperly.
> Should we really try to build a redundant checker?
> 2. The Boost header files for the libraries the user wants to use.
> Should we check for every file?
> 3. The libs/whatever/src and libs/whatever/build directories for any
> non-header-only libraries the user wants to use. Should we check
> for every file?
> I can't think of anything else. So what, precisely, should we check
> for, and what would the output look like if something were not found?
> > ADDTIIONAL scenario:
> > Lets say, in my compiler business, I have a scenario where I
> > occasionally release to the users a bug fixed header file. I send
> > mail with the new file and explicit instructions on where to put it.
> > After I have released a few bug fixed header files, I find users
> > complaining about weird problems. Turns out, I am now back to
> > an dreadful amount of time on the phone only to discover 9 times out
> > 10 the user did not follow instructions. 1 time out of 10 there
> > was a bug in something I released. 10 times out of 10, the customer
> > frustrated. Even if the customer REALIZES THEY made the mistake, it
> > still leaves them frustrated with ME and my PRODUCT.
> > So I elect to get a bit more extreme in my env checker.
> > I upgrade it so that it adds to the report a hash of all the "things
> > depends on", i.e. header files, link.exe etc.
> > So now, when the user has a problem, I have them send me the report.
> > can also make available to them a list of the hashes for the files
> > I have tested to "work".
> > I spend less time supporting my product, and my customers are
> > because I can keep them running much more effectively.
> > I have put a system in place to "Introspect" the users environment.
> > doing so, I have decreased the amount of time I have to spend
> > introspecting manually.
> I understand the principle, but I don't understand how to apply it
> effectively in our case.
> > HOW THIS RELATES TO BOOST.BUILD:
> > I need to understand boost.buiid better to give a better suggestion.
> > Hopefully my example might inspire the "Dependancies" to shake out,
> > if I do not fully understand boost.build yet.
> > I believe this STYLE of thinking can be applied, but I have to get
> > current boost things done before I can start down this track.
> > As I said before, if the thinking here inspires someone to START
> > something like this all the better . :)
> > IF NOT, I intend on tackling this in the future. (I first have to
> > a expert in boost.build though :))
> I disagree. Understanding what the system depends on does not
> require understanding all its internals.
> > I would like to eventually see something that allows someone to SPIT
> > a report, mail it to the list, and have the people on the list be
> > to IMMEDIATELY tell the person what could be horked, or why it is
> > building for them.
> That'd be great. The question is, what gets reported?
> Dave Abrahams
> Boost Consulting
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk