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

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-06-04 14:11:18

David- Some thoughts below

(sorry for taking a bit to come back on this one. I have been
contemplating)

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

At a high level all I am talking about is the same style of thinking
that goes into coding a unit test being applied to a runtime
environment.

maybe if I provide a different context: (to at least describe the style
of thinking I am espousing)

lets say I have developed a command line compiler that has a series of
dependencies:

* INCLUDE var needs to be set to a valid path
        * We assume some standard files are available here (stdio.h etc)
* LIB var needs to be set to a valid path
        * we assume some standard lib files- or Maybe just assume there
is at least ONE lib file there

lets say I have shipped my compiler to the masses, and soon I get
reports from the users that they have funky errors when trying to
compile something. Most of the time, it is USER error. In fact
frequently, I may spend hours on the phone with them only to discover
they did not configure something correctly or set it up properly.

in my frustration over time wasted I decide to write a env checker for
my compiler.

ill call it clenvcheck.exe.

when you run clenvcheck, if I elected to be extreme, I would:

1- validate INCLUDE and LIB vars are set
2- Read the contents of dirs to ensure some or all of the required core
files exist
3- display a list of these "dependencies" in my output report
        i.e. "found stdio.h at c:\brianscompiler\include"
4- check to see if I can find my linker- send the version and location
of it to the report
5- display a HIGH Level message denoting whether the "environment passed
the test" for my compiler.

so armed with this new tool I can now, when talking with folks over the
phone, ask them to run the report.

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.

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.

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

Cheers,

Brian "The Village Idiot" Braatz