Re: Devel::Cover and symbolic links -- borked?

[pjcj]

My best guess at what is happening is that the coverage for the symlinks is getting merged into one report (this is a feature), but that the symlinks are still getting reported on (this would be a bug). Could that be what is happening here?

Are you able to put together a test case? If so, please send it to RT (I don't really follow perlmonks) and I'll have a look at it. If not, just a bug report there would be better than nothing.

For future reference, the best place to report stuff like this is probably the perl-qa mailing list. Not that I have any problem with people discussing Devel::Cover wherever they want to - quite the opposite in fact - but when we get to bugs perl-qa or RT is probably needed.

I don't suppose there's any chance of getting your parallel modifications into the main distribution?

[DrWhy]

Well, that was easier than I thought. I wasn't even half-way through setting up the test case when the error popped up. It's not at the level of merging multiple runs as I expected, but in measuring the coverage of runs on the symlinks themselves. Here's your test case.:

File1
Name: main.pl
Content: print "hi\n"

File2
Name linkdir/main.pl
Content: symlink to File1

Run:
$ perl -MDevel::Cover main.pl
Devel::Cover 0.76: Collecting coverage data for branch, condition, sta
+tement, subroutine and time.
    Pod coverage is unavailable.  Please install Pod::Coverage from CP
+AN.
Selecting packages matching:
Ignoring packages matching:
    /Devel/Cover[./]
Ignoring packages in:
    .
    /usr/lib/perl5/5.10.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/vendor_perl/5.10.0
    /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi
    /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
    /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
hi
Devel::Cover: Writing coverage database to /path/to/cover_db/runs/1311
+608639.28154
----------------------------------- ------ ------ ------ ------ ------
+ ------
File                                  stmt   bran   cond    sub   time
+  total
----------------------------------- ------ ------ ------ ------ ------
+ ------
main.pl                              100.0    n/a    n/a    n/a    n/a
+  100.0
Total                                100.0    0.0    0.0    0.0    n/a
+  100.0
----------------------------------- ------ ------ ------ ------ ------
+ ------


$ perl -MDevel::Cover linkdir/main.pl
Devel::Cover 0.76: Collecting coverage data for branch, condition, sta
+tement, subroutine and time.
    Pod coverage is unavailable.  Please install Pod::Coverage from CP
+AN.
Selecting packages matching:
Ignoring packages matching:
    /Devel/Cover[./]
Ignoring packages in:
    .
    /usr/lib/perl5/5.10.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/vendor_perl/5.10.0
    /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi
    /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi
    /usr/local/lib64/perl5/site_perl/5.10.0/x86_64-linux-thread-multi
hi
Devel::Cover: Writing coverage database to /path/to/cover_db/runs/1311
+608812.28180
----------------------------------- ------ ------ ------ ------ ------
+ ------
File                                  stmt   bran   cond    sub   time
+  total
----------------------------------- ------ ------ ------ ------ ------
+ ------
linkdir/main.pl                        n/a    n/a    n/a    n/a    n/a
+    n/a
Total                                  0.0    0.0    0.0    0.0    n/a
+    0.0
----------------------------------- ------ ------ ------ ------ ------
+ ------

The problem is measuring code coverage at all when running a symbolically linked script that is not in the current working director. I didn't show the results, but if you run the same symlinked script without running the 'main' non-linked path first, then it captures the coverage. When you run main.pl first, then run linkdir/main.pl next that's when you get the failure.

update: Forgot to mention that you don't get this error when the symlink is in the same directory as what it links to.

[DrWhy]

I thought of that, but that is not the case. There is only one listing for each of the the symlinked scripts in the report and it's the one with n/a's all the way across. The behavior you suggested is the one that I hoped for and expected, all the usage for each script, no matter by which path, merged into one report line (preferrably in the name of the main, non-symlink path). Alas, such was not the case. I'll see about putting together a test case.