From: David Abrahams <dave@boost-consulting.com>
"Hendrik Schober" <SpamTrap@gmx.de> writes:
David Abrahams <dave@boost-consulting.com> wrote:
What should it say?
"Parsing jam file"? Or better yet: "parsing build rules"?
Well, it's much more than parsing. It's actually "evaluating" or "executing" them. I think "executing" would be misleading, so maybe "evaluating" would be better.
"Determining what needs to be built"? "Determining the work required to build Boost"?
So if that is insufficient to make it clear that the build will will work even without Python, what do we need to do in order to make it clear?
Maybe something along those lines: "Unable to find Python. Cannot build the Boost.Python lib. If you want to use Boost.Python, look at the docs at <link>. Proceeding with other libs..."
It's currently:
--------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** ^ Add a semicolon.
*** pass --without-python to suppress this message in the future ***
skipping Boost.Python library build due to missing or incorrect configuration ...
---------------------------------------------------------------------
How's that?
Looks perfect (with the semicolon).
Um, what are targets?
Standard build-system-eze for "element of the build dependency graph." These messages are inherited from jam; should we remove them?
I don't think so. But maybe some explanation in the docs (in non-build-system-eze) of what they are would be good.
Why shouldn't the tool output messages in non-build-system-ese? [...]
Oh it should. I didn't say anything against that, did I?
Well, no, but telling you that we found 4471 targets and we're updating 1123 of them has to be more cryptic than helpful!
How about something along these lines: Found 4471 items to build, of which 3348 were already current. Updated 1123 items.
Well, what do you think? I mean, of course, dots while there's success, and error messages when there are errors.
Mhmm. Not seeing anything is always distracting. Seeing to much isn't good either. So the dots are probably a good idea.
Okay.
There's always the old standby approach of printing, in succession, the following strings: "\r-" "\r\" "\r|" "\r/" repeat That avoids spewing thousands of lines or characters of output, yet gives active feedback. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;