On Mon, Mar 07, 2005 at 11:24:42AM -0700, Jim Cromie wrote:

> Michael G Schwern wrote:
> 
> >That's ok.  The overall coverage report can show the union of all
> >reports for that version of the module.
> 
> That'd be cool, but how does this merge/combining magically happen ?

To do it properly it would need to be on a machine somewhere which would
accept uploaded coverage databases from anyone who wanted to submit one.

I discussed cover.perl.org or something with Andy and Robrt on irc a
while back, but I've not made progress on the sw side.

> More specifically, Ive found it to *not* be happening when I spawn off
> an `$^X -MDevel::Cover -e $testcode` job, as you've noted in another thread.
> OTOH, it does seem to merge repeated runs of 'make testcover', as I see the
> ran-this-line counts in the coverage report go up after each run.

Provided you can get each run using the same database things should
"just work".  If your pwd moves around you might need to specify a full
path to the db.

    export PERL5OPT=-MDevel::Cover=-db,/path/to/cover_db

or something similar might help.

> so, wrt merging coverage results, I looked inside cover_db/cover.12,
> a storable file w multiple runs, one for each t/*.t file, each with a 
> unique key:
> 
> $ mst -d cover_db/cover.12 |egrep -e 'run|111'
>  'runs' => {
>    '1110216257.25137.60188' => {
>      'run' => 't/pp-dump.t',
>    '1110216248.25129.46205' => {
>      'run' => 't/labels.t',
>    '1110216234.25117.50538' => {
>      'run' => 't/basic.t',
>    '1110216267.25145.50509' => {
>      'run' => 't/warns.t',
>    '1110216241.25123.18273' => {
>      'run' => 't/honorLocals.t',
>    '1110216253.25133.53184' => {
>      'run' => 't/new.t',
>    '1110216255.25135.61883' => {
>      'run' => 't/pod.t',
>    '1110216260.25139.29174' => {
>      'run' => 't/speed.t',
>    '1110216229.25107.07159' => {
>      'run' => 't/alias.t',
>    '1110216250.25131.38534' => {
>      'run' => 't/multiarg.t',
>    '1110216243.25125.33249' => {
>      'run' => 't/indent-terse.t',
>    '1110216239.25121.64393' => {
>      'run' => 't/emulate.t',
>    '1110216226.25105.54436' => {
>      'run' => 't/01_use.t',
>    '1110216262.25141.01103' => {
>      'run' => 't/twoObjects.t',
>    '1110216265.25143.07361' => {
>      'run' => 't/useoptions.t',
>    '1110216231.25109.28610' => {
>      'run' => 't/autoprint.t',
>    '1110216246.25127.34447' => {
>      'run' => 't/initobj.t',
>    '1110216236.25119.49831' => {
>            4111,
>      'run' => 't/chains.t',
> 
> 
> the file doubles in size when I rerun `make testcover`.
> It would be easy enough to lump them together,
> though by itself, this wouldnt help identify platforms
> where a module is undertested.

The runs should be lumped together automatically when you run cover.
There are also options to cover to merge separate coverage databases.

> anyway, we need site-space and cpu-time somewhere to merge
> the data.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Reply via email to