On 7/23/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>   > Are you suggeting that ExtUtils::MakeMaker go into Bundle::CPAN?  That's a
>   > very good idea.

While we're at it, ExtUtils::Install, ExtUtils::Command and
ExtUtils::Manifest.  Though ExtUtils::MakeMaker ships with a set that works.

ExtUtils::Install++  (With caveat about whether it can be installed on
older Win32; though it's a requirement for *newer* Win32 Perls to
properly install core modules upgrades directly from CPAN.)

>   > If parsing the error message is a "convention" that should be avoided, 
why is
>   > parsing out the prerequisite warning not?
>
> Nobody is parsing the prerequisites warning, we are only parsing
> specified prerequisites.

Sorry, I don't think I follow.  Could you explain the difference?

I don't think CPAN.pm cares -- it only needs to know if the
Makefile.PL/Build.PL ran with an exit code of zero.  However, I hope
to soon have CPAN::Reporter involved in CPAN.pm's PL/make cycle as
well as the test cycle.  When that happens, I need to know whether the
exit is due to an error (FAIL) or because of an unsupported OS or Perl
(NA).

For that, I already will have to parse the output looking for the
strings "OS Unsupported" or "No support for OS" because that's the de
facto approach that CPANPLUS uses and Barbie endorses for
CPAN::Testers.  I was hoping to avoid more parsing for the 'require
5.XXX'' error message and use prerequisite metadata. I think that's
better design, but the extra effort to parse for the error is pretty
much just an extra elsif.

David

Reply via email to