On Sat, Aug 30, 2008 at 2:51 AM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > I'm trying to understand why the cpantesters require the Build.PL file > to exit with success rather than just die. > > What is the logic behind this and is there anyway to change that?
Here's the logic that shows why this is neccesary with CPANPLUS and CPAN+CPAN::Reporter: * If Makefile.PL or Build.PL exit with a non-zero exit code, a distribution is graded FAIL and a report is sent (but see "downgrades" below) * If they exit with a zero exit code, no grade is assigned and CPAN and CPANPLUS proceed to the next step (make/Build) * If no Makefile or Build file has been generated, then CPANPLUS and CPAN abort processing. (No CPAN Testers report is sent.) * If make/Build fails (such as due to missing binary or library dependencies), the distribution is graded FAIL and a report is sent (again, see "downgrades") So the idea of "exit 0" is to have a "controlled exit" as opposed to a failure. It's an *intentional* exit that -- by not generating a Makefile or Build file -- signals that processing shouldn't continue. Now about downgrades -- both CPANPLUS and CPAN::Reporter parse the output of PL/make/test stages looking for reasons to "downgrade" a FAIL report either to NA or just to discard it. Examples: * "use 5.XXX" errors (all the variations of them) are detected and result in NA * The phrases "OS unsupported" or "No support for OS" are detected and result in NA (this because the legacy approach was: die "OS unsupported") * missing *Perl* prerequisites (PREREQ_PM or requires/build_requires) result in the report being discarded and not sent > I've recently had to try to explain it to a new author and frankly I > just don't get it. This is a good reference as to "how" -- sometimes with "why": http://wiki.cpantesters.org/wiki/CPANAuthorNotes But talking about it as a "graceful exit" or "controlled exit" that avoids a FAIL report is the shorthand way to do it. > And having just updated Linux::USBKeyboard (so now I'll get zero reports > instead of all fails?), I find it rather clunky to be writing warn() > followed by exit() when die() would be shorter, as well as just good > practice in any normal code. Clunky, but correct, at least according to the semantics of Makefile.PL and Build.PL in the build process. Plus "warn XXX and exit 0" is only 12 characters longer than "die XXX". And you can shave it to 10 if you just say "and exit". (We teach it as "exit 0" to make the point that the exit code must be zero for it to have the desired effect.) That's not much overhead when you only need to write it once. > Why is it that writing Perl modules and posting modules to CPAN "the > right way" require separate sets of documentation? I would guess that 95% or more of CPAN has no dependencies that will ever require "exit 0" so most people aren't affected. And it's not about "the right way" to post modules, it's about the right way to disambiguate real errors from missing prerequisites. You can write "die" on missing prerequisites if you want, as long as you realize that CPAN Testers can't tell that from an error condition that you (or others) might actually care about. That said, there are ways to make this a bit "easier" at the cost of packing up modules in inc. See Devel::CheckOS and Devel::CheckLib. Someone could go write Devel::CheckBinary or whatever. What would avoid all this hassle is to have a well-defined way for people to specify their non-perl dependencies in META.yml, and then have M::B and EU::MM check those in a consistent way. Of course, that only works if newer versions of M::B and EU::MM are installed, so you also then need "configure_requires" in META.yml. But that only works if a recent enough version of CPAN or CPANPLUS is installed to know to check configure_requires... and we're back to the maze of twisty passages. Or just "exit 0" and be done with it. -- David
