Re: [boost] Boost Build Env Checker (was RE: Re: CustomerFriendlier Boost Installation)

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-06-12 13:17:01

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

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto: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
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
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