Outputting build summaries instead of details

"Noel Belcourt" <kbelcosandia.gov> writes:

> We'd like to control what information our customers
see on stdout when 
> they run our product's installer (bjam) at their
sites.
>
> For example, when we deliver them software, we setup
bjam to build in a 
> bootstrapping mode to build as much of our code base as
it can.  The 
> problem is that we have about 100 libraries to build
containing some 
> 30000 source files, about 50 executables to link and
lots of tests to 
> run sprinkled throughout the build process.  The amount
of information 
> output to stdout by bjam is overwhelming to our
customers and is really 
> only useful to us.  That's why we'd like all the
normal bjam output 
> redirected to a file that, ideally, we can name with a
property in the 
> Jamroot.
>
> Instead of the detailed bjam output to stdout, we'd
rather have a 
> summary line output for each lib, exe and test target
as it is built 
> and run.  This summary information would be much more
manageable for 
> our customers and, because the summary line is output
as the target is 
> built, it would provide temporal feedback to the
customer about the 
> build/run time required for each target.  If our code
doesn't compile 
> cleanly or a test fails, we'd like the summary to
count the number of 
> warnings and errors (or the number of files generating
these messages) 
> and output this information to the summary line as
well.  Naturally, if 
> the customer has build or test problems, we could have
them send us the 
> summary and detailed output for us to look at.
>
> A representative summary line for three library
targets.
>
> Building netcdf 3.6.0, 3 warnings, 0 errors finished.
> Building exodus 4.15, 1 warnings, 0 errors finished.
> Building nemesis 3.03, 7 warnings, 2 errors not
finished.
>
> Has anyone done something like this or know how to?  

It's tough.  Don't forget that there's no guarantee of
particular
build ordering and builds can be parallelized.  That said,
I'd be very
interested in such a feature for Boost, so I encourage you
to try to
implement it!

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build