All the Perl that's Practical to Extract and Report

blib hatred

glasser on 2005-07-14T15:06:02

You know what I hate? blib.

You see, I almost exclusively write pure-Perl modules. Thus, the "make" step always consists of making a structure under "blib" that consists mostly of empty directories, copying all my .pms into "blib/lib", and manifying pods into blib/man3.

This is useless for me while developing. I don't actually care about manifying PODs until I'm ready to "make install" anyway. And copying the modules just means that sometimes blib/lib is out of date when I'm running "prove" (or even "make test", if I just made a new module and haven't reran Makefile.PL yet), and more annoyingly they show up in every grep, and have to be ignored by version control, etc.

I suppose part of my annoyance would be fixed by making a shell script that uses "prove -l" to simulate the effect of "make test" using modules from "lib" instead of "blib/lib", and just never run "make" or "make test" while developing. But still. Ugh.

A plug for Test::Verbose

Matts on 2005-07-14T16:59:48

prove is very similar (in my opinion not as good, but I don't mean that as anything against the prove developers) to the "tv" command from Test::Verbose. This might fit your needs better as it's an interface to "make test" rather than something that runs the tests directly. Try it and see if you like it.

prove++

jplindstrom on 2005-07-14T17:28:48

I usually just run prove from within the t directory and put a
use lib "../lib";
in each test file.

Re:prove++

wnodom on 2005-07-15T16:28:29

prove respects the -I command-line option (and you can stack them the same way you can with perl itself):
prove -I/some/project/lib -I../lib
It also looks for a PROVE_SWITCHES environment variable, which I usually load up with something like this:
-I/some/shared/lib -I/my/project/lib
This way, I don't have to modify the test scripts at all, and if I use absolute paths, I can run the tests from whatever directory I happen to be in at the time.