On Apr 4, 2007, at 6:39 AM, Paul Cochrane wrote:
On 04/04/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Apr 3, 2007, at 11:29 PM, Will Coleda (via RT) wrote:
> # New Ticket Created by Will Coleda
> # Please include the string: [perl #42293]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42293 >
>
>
> These two scripts perform the same basic task, but do so
> inconsistently.
>
> The tools/ script should be removed, and someone should investigate
> how it's checking the pod (it finds errors in the current distro
> while the test does not.)
>
> --
> Will "Coke" Coleda
> [EMAIL PROTECTED]
I just ran tools/doc/pod_errors.pl and I ended up getting a segfault.
That's interesting; what OS are you using? I'm using Gentoo linux x86
and found with, for example, the t/codingstd/c_indent.t test would
cause (the gentoo package) perl to segfault. However, I've compiled
my own version of perl (same version as well 5.8.8) and it runs the
tests fine and the tools/docs/pod_errors.pl test runs. Anyway, the
reason I'm interested is because I was wondering if the segfault were
a Gentoo perl proplem.
I'm running darwin, ppc. The perl is 5.8.7 and was updated by me. I
don't think I've gotten perl to segfault in quite some time, and if I
trust my crashreporter log, the problem almost always is in S_regmatch,
but I'm not sure which file actually does the checking, too much
inheritance runaround.
But under tcsh, `find . -not \( -name .svn -prune \) -type f -exec
podchecker '{}' \; | & grep -v 'does not contain any pod commands' |
grep -v 'pod syntax OK'` gives me far too many errors and warnings to
be good. Seems as though podchecker is stricter than our pod checker.
That's odd, as I fixed a failing pod test a while ago where an extra
C<=cut> was in a C<.pmc> file and podchecker said everything was hunky
dory, but t/doc/pod.t was complaining. Running the file just through
perldoc didn't seem to throw up anything either. So it seems that at
times podchecker isn't as strict.
The output from tools/docs/pod_errors.pl at least gives information
about where the problem is in the file, which is something that
t/doc/pod.t unfortunately doesn't.
Just my 2c.
Paul
So we have three methods to test for pod errors, and three different
standards for the pod. Seems as though this ticket got a little more
complicated.
