On Sat, Aug 30, 2008 at 2:24 PM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: >>* The phrases "OS unsupported" or "No support for OS" are detected ... >>* missing *Perl* prerequisites ... > > So, there is a mechanism for detecting die() messages, but it doesn't > support any sort of "Missing external prerequisite" flag?
The general view of those writing/maintaining CPANPLUS and CPAN::Reporter and other who influenced us is that we don't want to head down the road of supporting more and more "magic text" parsing. It's just as arbitrary as "exit 0" and more prone to user error. For example "OS is unsupported" is not the right incantation. Devel::CheckOS wraps the incantation into an interface to help avoid that problem. I think that's the better approach. > we remember to die in one case and exit in another? Would some kind of > general-case prefix in the error message be a better way to handle this > and future issues? It has positives and negatives. The parsing is done out of the combined STDOUT and STDERR of the entire command. For tests, that includes all TAP and test output. The more text parsing we do e.g. your "STOP: XXXX", the greater the risk that some test happens to have the same output. > It would also be nice to have at-a-glance reporting of what exactly FAIL > means. Did it fail to start, fail to build, or fail during the tests? > For that matter, even N/A is a bit ambiguous, no? That may come whenever we get to CPAN Testers 2.0 (by "Christmas") where we capture reports with structured data. So you can see that something is a "PL FAIL" or a "make FAIL" or a "test FAIL". Right now, there's too much email subject/message text parsing to make that change a high priority. We couldn't even get consensus a while ago on adding the Perl version to the email subject line because it breaks too many things in the ecosystem. David
