On Behalf Of David Abrahams Subject: [boost] Re: Customer Friendlier Boost Installation

"Brian Braatz" <brianb@rmtg.com> writes:

...

Wild thought-

Is there a rational way to have a "environment" checker. I am NOT a bjam expert- but it would be handy if we had some cmd line program that would follow spit out all the info BJAM looks for and finds.

I am slightly half cocked in this idea, but basically it would have to be enough information that you could get a better sense for what Bjam was doing

Something like

C:\boost\> boostenvcheck.exe ** Enviroment Report** Python is not in the path User-config.jam file is setup to use gcc, vc7.1 Etc....

[David Abrahams Writes:]

If you're talking about user-config.jam you're talking about BBv2.

First question: how would this information help people? They can go look at their user-config.jam themselves, right?

Hmm.. My apologies for not fully explaining myself. I will explain the concept I am speaking from FROM A GENERAL sense first, and then relate it to boost. BACKGROUND: I have had good success with the following paradigm: GENERALLY, if you have app you are deploying to MANY sites and you need to support those sites, it is extremely valuable to build a program which analyzes the environment and spits out a report. This is useful for both on site techs and trouble shooting over the phone. How you build such a program is ask yourself the following questions: 1- What are the configuration assumptions my application requires? 2- What concepts does my application *assume*? Once you have identified these, you then build an application which allows for introspection of the environment. Generally it is usually something that spits out a report that checks all the "assumptions" of the tools and displays the conformance to the assumptions. Think of this concept as "unit testing" for an environment or product. You can also think of this as a "blood test" for a patient. :) PRACTICE: Generally, over many companies I have worked with, I have had a *DIFFICULT* time getting developers under my leadership to see the value of this thinking. The mental shift for folks with this thinking is "well we should just make sure the systems are configured properly. What you are saying we need to do isn't necessary. The users (or techs) need to learn to read the docs.". In practice I have found applying a tool like this invaluable. Everytime I have gone through this cycle with folks, they EVENTUALLY SEE that value. The pain of trying to support something deployed allows for people to "feel" the value. But it is always hard to get the developers to "go there". This is something I have yet to understand why people have an aversion to this thinking. It can save a company's proverbial butt by significantly reducing the down time and trouble shooting time of an environment. Even if you have standards, and train people, and put systems in place to enforce those standards, chaos always finds a way of creeping in. BOOST: To me this is a piece that is missing that stops wider adoption. I have taken the proposed boost profiler, added A LOT to it, integrated it into a production application and shared the techniques and concepts with my developers. I have purchased the MPL and Modern CPP books for my people and have been busy helping folks implement some modern techniques into their designs. I now have an entire team excited about boost. Extremely excited. Their excitement and the time I have spent fostering that has SLOWED my ability to get a "next cut" of the profiler out for review. REMEMBER: I am not ashamed to recognize myself as the "Village Idiot" on this list. I DO know more about boost and template programming than anyone in my company, but I am in NO WAY SHAPE or form as knowledgeable as the fine people who frequent the list. What is interesting though as I watch this process, is I am SHOWN CLEARLY why boost is not adopted by the normal programmer. Many things the rest of you guys KNOW and take for granted are not easily grasped by people. I believe this pattern forms as people get smart, the things they see as obvious grow in complexity as they become smarter. I noticed the other day a post where someone was NOT getting a concept, the response to the person was basically "Documentation should not cover things that are obvious". That struck me and I have discussed that mail with some of the folks under my leadership, using that as an example to discuss difficulties in communication. I understand boost better than anyone in my company, but I have to tell you it REALLY shows how hard this stuff is to get your head around by watching CLOSELY someone stepping into it for the first time. I have written several samples and have spent hours explaining boost.function for example. This is a lib, most people might see as "obvious" (me included). There are obvious limits to what can be documented, and there is always going to be a barrier to entry. With boost that barrier is huge, I believe it to be bigger than EVEN I initially thought as I try to bring my team up to speed on what I know. HOW THIS THINKING RELATES TO AN ENV CHECKER IN BOOST: On a windows box, one used to be able to run MSD.exe, which would spit out a report for your configuration. XP allows one to still run sysedit.exe. This program is outdated (it is from Win3.1) but it shows you your configuration. In the old days people us3ed these tools to better support the system. I AM NOT a BOOST.BUILD expert. I believe the "how to think about this" I am presenting is valid (I see it everyday working with people using boost for the first time). I am unsure if the explicit idea is valid due to my remaining limited understanding of boost.build. HAVING said that here is the suggestion, reformed: Boostenvcheck.exe become s a program which LISTS the dependencies for your configuration. How to identify WHAT it lists requires someone more knowledgeable than me about it's dependencies and configuration assumptions. Once one has this tool then, just like a general software app, one can say to a newbie on the list "run boostenvcheck.exe" in your boost dir and send the report to the list. If the report is well formed, the people on this list should be able to scan the report and QUICKLY help someone out. Think of this like a "blood test", it measures and reports all the assumptions and parameters. Overtime, just like a doctor, the folks on this list will develop an intuition for the values in the report and be able to quickly help people resolve issues. ( SIDE NOTE: I interviewed a Dr recently (requirements work) and he was telling me about his intuitive sense he has gained over reading blood tests and troubleshooting problems) EXECUTION: (or "Finishing current tasks") :) I am currently working very hard on bringing what I learned about profiling and introspection to this list. I have to take the code I integrated with the app (conforming to internal ways of doing things) and boostify it enough for presentation, it is also gaining scope and functionality and being redesigned. I have been working for the last 6 months on the profiler and moving that forward (not just technical, we have taken my code through QA and put it into production). I regret this has kept me largely off list, but it has been a huge learning experience about "actual" introspection (not just logging or profiling- there is a deeper concept here I am not seeing anyone else address on this list or in this industry) My plan is to do this: - Get the profiler re-written to work alongside the other pieces I have learned are needed - Get this sent out to the list so people can finally SEE what I have been working on (there is a connection to the excellent work John T has been working on with logging- but these two concepts are not mutually exclusive- logging is just one piece of introspection) - Get some of the other pending library submissions I have not had a chance to finish "out there" for people to see and tear apart. - Get "down and dirty" with boost.build and SPEND the time to learn that sucker. Once I have done this, I can then formally propose an actual "working" boostenvchecker program and everyone have an easier time "seeing" what I am talking about. In general, I LOVE BOOST, and have devoted as much time as I can suck out of my production world to finding ways to contribute my perspective. I have taken to going to bed REALLY early so I can get up early every morning and work on bringing the profiler \ tracer to boost. I am now getting in a good 6-8 hour day prior to my work day starting. There are so many things I would like to contribute. I believe my "village idiot" perspective, if executed correctly, can provide considerable aid to people adopting boost. I just simply have to focus enough effort to SHOW people what I am talking about. Sample code \ tools communicate better than words sometimes. If someone "sees" what I am talking about and wants to move if forward before I get there. ALL THE BETTER. :) Sorry for the long response. But what I have explained for anyone reading this is where I am coming from. Anyone who follows this will see a consistency between this mail, past mails, and future actions.

First problem: .jam files are programs, not just configuration, like .ini files. We can't capture everything a user might want to write there in English.

...

I have been using boost for (has it been that long) 2 years now.

Bjam

...

still confounds me. ( I appreciate the work effort, it is a cool tool, I remain struggling with it though)

[David Abrahams Writes:]

You never post questions; how can we improve its interface and help you understand it otherwise?

Excellent point indeed. I need to do more of this. I tend to take a LONG TIME to learn something, once I have it, I have it well. But the first initial barrier is tough, and my initial questions are frequently so idiotic I don't always get the information by asking the question. I have read the MPL book now FIVE TIMES cover to cover. On the fith pass, I "saw it". (the mpl::for_each<> is what kicked it in for me) I have been now writing programs using the MPL library (kudos to both you and Aleksey- excellent body of work). Because I know I have to go through this learning process, I work very hard up front to "see it" enough so I can answer my own conceptual questions first. Basically though, your advice is well received by me. I need to ask more questions, and will do so in the future. I have a personal goal of learning everything I can about boost as this will help me contribute.

...

(I am also a tad frustrated because I have been trying to make vc7.1 build wave for the last 5 hours)

Semi-Related:

I proposed (a long time ago) building a SIMPLE gui framework- with the core elements, and then making a "boost environment checker" out of that- I.e. imagine a tree control with all the types of settings and what nots, and the ability to navigate this gui to try to determine what is not set correctly.

Might be a good idea; we can't really know until we see one, though. [Brian Braatz Writes:] YES. THIS IS THE BANE OF MY EXISTANCE. So much to code, so little time. :)

I realize I "come from a different place" in my thinking. And I realize that to truly communicate what I am talking about I have to show it. I am just frustrated than I require sleep. If I didn't need sleep I could spend more time learning more about boost. :) CONCLUSION: Dave- Thank you very much for your thoughts and advice. Everyone- I see everyday in people I am working with the incredible hair raising effect and energizing influence bringing boost into my dev team has had. I am grateful for everyone's dedication to creating some incredible works. THANK YOU ALL, "The Village Idiot" :)