Control: reassign -1 libperl-critic-perl Russ Allbery <r...@debian.org> writes:
> This may acutally be a bug in Perl::Critic or perltidy, but since this > is the interface I'm calling, reporting it here. > With this upgrade: > [UPGRADE] perltidy:i386 20120701-1 -> 20130922-1 > Test::Perl::Critic now leaves perltidy.LOG files behind in the current > directory after the test has completed. Since the results are all > reported via normal test results, this seems pointless, and it leaves > build clutter behind. I looked into this further. The problem is that Perl::Tidy now always attempts to create a log file in the current directory unless told to create it elsewhere with the logfile parameter to its constructor. (There doesn't seem to be a way to tell it not to create the thing, although maybe you can point it to /dev/null.) Perl::Critic's policy for running Perl::Tidy doesn't pass that parameter or provide any way for the caller to pass it. That makes this more Perl::Critic's problem than Test::Perl::Critic. Reassigning accordingly, although arguably this is a perltidy bug and perltidy should stop writing files into the current directory unless someone actually asks for them. (I'm a bit grumpy because I spent two hours debugging this.) Note that this new behavior also breaks builds where the source directory is readonly, a technique used by, for instance, Automake's distcheck target to ensure that source files are not modified incorrectly by the build. This therefore broke the builds of some of my packages that use Test::Perl::Critic to test the style of Perl scripts embedded in Automake-managed projects, since those tests are run from the read-only source directory, not the build directory, so that the test infrastructure can find the source Perl scripts to check. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
