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 ;-) But I can explain what is happening at a low level. For the first forty or so releases Devel::Cover would collect coverage data for each run by noting which ops were executed and then, at the end of the run, it would look through each subroutine and match the constructs in the subroutine with the coverage of the ops to produce the metrics for that run. These data would be stored for each run, and when the cover program was eventually run they would be merged to produce the final report. 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. 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. 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. 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. Thanks for reading this far. I must stop now as half time is over, so it's back to the football ... -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
