Finally replying to this; sorry for the delay.
On Jun 17, 2004, at 12:50 PM, Paul Johnson wrote:
On Thu, Jun 17, 2004 at 09:31:48AM -0700, David Wheeler wrote:
I checked in a bunch of changes to my module last night, and then the nightly process that runs cover on it output these lines:
Devel::Cover: ignoring extra subroutine Devel::Cover: ignoring extra statement Devel::Cover: ignoring extra statement Devel::Cover: ignoring extra subroutine Devel::Cover: ignoring extra statement Devel::Cover: ignoring extra statement
Anyone know what they mean? What extra statements and subroutines?
Good Question! It's a shame you checked in a bunch of changes rather than one small change, otherwise you could have told me ;-)
<snip/>
This worked well, but had a couple of drawbacks, so a little while ago I
changed things rather fundamentally. Now, at the end of a run there are
two sets of files created. One, which contains the structure of the
program - where the subroutines, statements, branches and conditions
are, and the other which contains data about how many times each
construct was exercised.
But the structure data only needs to be created if it does not already
exist, so subsequent runs can benefit by not have to create and store
these data. The main advantage, however, which is as yet unrealised, is
that the data for different runs can be directly compared, which should
yield some interesting information.
The curious thing is that I delete the contents of the cover directories after every run, so it shouldn't be updating the data structure at all--unless it gets checked before every test, because I do have a number of test scripts.
But there is a downside to all this. It's called Perl.
Perl is so dynamic that the structure of one run may differ from the structure of another. I suppose this will happen when a subroutine is created at run time in one run but not in another. This would ultimately be through an eval, but might be hidden behind an AutoLoaded function or something similar.
Yes, and I use Class::Meta to generate accessor methods (among other things) in BEGIN blocks. Could this be causing the noisiness?
What happens then is that on attempting to add collected data to the run
information the (first) structure is searched, but the construct is not
found, and this warning is emitted.
In practise this means that those constructs will not be considered as far as coverage is concerned. This is a bug, and I've just added it to the TODO list.
I look forward to a fix. :-)
If anyone is able to reproduce this with a small example I'd be very
grateful to receive it, otherwise I know of a number of larger modules which also exhibit this problem.
Hrm, tuits, tuits, tuits--anyone got any to spare?
Cheers,
David
smime.p7s
Description: S/MIME cryptographic signature
