From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-25 02:10:15
Beman Dawes wrote:
> At 04:35 PM 2/23/2003, Rene Rivera wrote:
> >Some organizational items... Here's a TODO list for Boost.Jam.
> > ...
> >* Add the timming output Beman wants for the basic build actions.
> >- Difficulty: MEDIUM.
I think we should not do it until we start implementing testing support in V2,
since it might end up quite different from V1.
> Timing breaks down into two components:
> * Build (compile/link) timing.
> * Run timing.
> Now I'd certainly like to be able to report build timings, too, but it is a
> medium or even low priority request.
> Would it really be that hard anyhow? Couldn't you just wrap all applicable
> build commands (c action, c++ action, link action, etc) with a call to a
> timing program (which starts timer, calls system with the args ( being
> the program to execute), reports timer, returns)?
It looks like this is the same idea I always had. There are very many special
ways to perform build/run actions during testing. Measuring elasped time or
consumed memory is obvious. Killing a test after 10 mins is another (from
regression tests hangup reports I understand Boost.Test can't do that yet?).
Running tests under valgrind to catch uninitialized variables in yet another.
So, we need a generic way to specify "launcher" --- the program to really
execute the build action -- IOW, to "wrap build commands". If we have then,
we'll have to say that lanucher for build actions is "timer" and have the
I'd like to push this a little bit further: we can wrap all command in a call
to program which will not only report time, but also record exit status,
output, etc. This way, Boost.Build will only run tests, all the reporting
will be done by a separate utility. This is attractive for me because bjam
is really not good at generating reports or measuring execution time, or
anything like that. Adding such abilities to it seems not better than using
a separate program.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk