-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Monday, June 06, 2005 5:18 AM To: boost@lists.boost.org Subject: [boost] Re: Boost Build Env Checker (was RE: Re: CustomerFriendlier Boost Installation)
"Brian Braatz" <brianb@rmtg.com> writes:
boost-bounces@lists.boost.org wrote:
On Behalf Of David Abrahams Sent: Tuesday, May 31, 2005 7:08 AM To: boost@lists.boost.org Subject: [boost] Re: Customer Friendlier Boost Installation
"Brian Braatz" <brianb@rmtg.com> writes:
HAVING said that here is the suggestion, reformed:
Boostenvcheck.exe become s a program which LISTS the dependencies for your configuration.
Can you show an example of what that output might look like? I don't even 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 interoperate, 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
David, belated response- 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 right now * 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 build * debug my own build problems- and make careful notes on "what the problems were" * 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 possible) * 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 learned. Thank you David for a very useful conversation. :) Brian head.
<snip example of non-Boost environment check>
when it says "passed"- I can quickly re-direct them back to their
code.
if they are not convinced, I can have them send me the report and I can 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 site-config.jam.
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 out a 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 spending an dreadful amount of time on the phone only to discover 9 times out of 10 the user did not follow instructions. 1 time out of 10 there actually was a bug in something I released. 10 times out of 10, the customer is 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 it depends on", i.e. header files, link.exe etc.
So now, when the user has a problem, I have them send me the report. I can also make available to them a list of the hashes for the files which I have tested to "work".
I spend less time supporting my product, and my customers are happier because I can keep them running much more effectively.
I have put a system in place to "Introspect" the users environment. By 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, even if I do not fully understand boost.build yet.
I believe this STYLE of thinking can be applied, but I have to get my 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 become 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 out a report, mail it to the list, and have the people on the list be able to IMMEDIATELY tell the person what could be horked, or why it is not building for them.
That'd be great. The question is, what gets reported?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost