On Sun, Jun 28, 2015 at 09:18:57AM -0400, James E Keenan wrote: > On 06/27/2015 01:55 PM, yary wrote: > >I believe that Devel::Cover excludes core modules, so that "your code" > >isn't influenced by modules that are included (perhaps indirectly). Seek > >out a switch/hash/regexp/sub to modify that behavior, there is one > >somewhere!
I'm not convinced this is the problem because the file is actually being reported on, it's just that the report says the coverage is 0. Devel::Cover doesn't ignore core modules in the sense that it knows which modules are core and alters behaviour for them. But it does have ways of ignoring modules either based on their names or their locations. By default all of the modules in all of the directories of a pristine @INC are ignored. This effectively ignores core modules and all other installed modules which, usually, is what you want. Ignore here means not to collect coverage data. The code is obviously still run. If Devel::Cover has got things wrong then this can all be altered with command-line options, you shouldn't have to go grovelling around the code. However, in this case, the modules have not been installed and so they won't be in that location and, by default, will not be ignored. This is why the coverage is reported, albeit as 0. > >On Fri, Jun 26, 2015 at 10:08 PM, James E Keenan <jk...@verizon.net> wrote: > > > >>Richard Elberger and I recently received co-maintenance bits on the > >>File-Path distribution. As is my wont, I ran it through Devel::Cover -- > >>but was surprised to see that 'cover' reported zero coverage. > >> > >>Does anyone know why File-Path is unresponsive to 'cover'? I think the problem here is that Devel::Cover cannot provide coverage for modules it uses itself. For this reason I try to keep Devel::Cover dependencies to a minimum. File::Path, however, is one of the dependencies. This is described in to docs: https://github.com/pjcj/Devel--Cover/blob/master/lib/Devel/Cover.pm#L1611 This means, I'm afraid, that there is no easy solution to getting Devel::Cover to run with File::Path. > Thanks, yary. Yes, after I posted I recalled that Devel::Cover does > exclude core modules. IIRC, pjcj had a project called 'p5cover' > which was intended to rectify that, but I don't know that project's > current status. Languishing, I'm afraid. But even if it were working it could not provide useful data for File::Path for the reason mentioned above. > In any case, on my previous laptop I located some correspondence > with pjcj from two years ago in which I reported having found a hack > for this case: Create a branch. In the branch rename 'Path.pm' to > something like 'ABCPath.pm', then do a global search-and-replace in > all files (except things like README, TODO and Changes) to impose > the new name. At that point you can run 'perl Makefile.PL && make', > and from that point Devel::Cover sees a brand new library and > calculates coverage. Yes. This works because the module is then separate from the standard File::Path. I suppose a solution could be to bundle File::Path with Devel::Cover but under a different name. Or perhaps take the parts of File::Path which Devel::Cover uses and "inline" them somehow. The same argument could be used for the other modules Devel::Cover uses itself. I am not enamoured of these options but they might bear thought. Devel:Cover is also unable to provide coverage for itself, for the same reason. I have worked around that partially within Devel::Cover by providing a reduced coverage option which uses the older method of replacing the runops loop rather then replacing function pointers for ops, and doesn't suffer from the same deficiency. There is a small chance that you might get coverage for File::Path by setting DEVEL_COVER_OPTIONS=-replace_ops,0 but I have not tried it and wouldn't like to bet on it. But if it doesn't work and anyone would like to dig into it, that is where I would start. -- Paul Johnson - p...@pjcj.net http://www.pjcj.net
