NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
A man, a plan, a canal (Score:1)
What is this short-sightedness of Test::Pod to try and declare it's own plan automatically of which you speak? Maybe I'm missing some cool functionality doing it the following way, but it seems to work well enough for me.
Re: (Score:1)
Doctor! Doctor! It hurts when I do this! (Score:1)
Don't do that, then.
Use pod_file_ok and spell it out longhand. My latest thinking on the matter looks something like this [mongueurs.net], which I think is on the right track, although I'm still not happy with the redundancies in, for instance, $test_pod_coverage_tests and @coverage.
Re: (Score:1)
The entire point of the short versions is to have one simple script I can have my release automation automatically copy into place as it's building the release distribution.
Manually maintaining it all would be a massive waste of my time.
Re: (Score:1)
Oh yeah, I forgot that you do have quite a number of modules, don't you :) I guess I'm not playing in the same league.
Still, could this not be driven by extracting candidats from MANIFEST? Looking for all .pm files under lib or the base directory of the unpacked distribution?
Re:Doctor! Doctor! It hurts when I do this! (Score:1)
An Example Module in my SVN Repository [svn.ali.as]
The only two files that I need in the root of my CPAN modules in the repository are Makefile.PL and Changes, which hold actual canonical information.
The rest can be derived (yes I know I shouldn't use pod2man for README files, but I don't have anything better yet).
Reply to This
Parent