If you read the grade definitions, this particular case is properly graded as a "FAIL" -- but I agree with you that it's probably shouldn't be since, conceptually, it's a failure in a prerequisite. This is part of the broader problem of how CPAN distributions can/should specify non-perl dependencies (e.g. libraries, OS, etc.).

As a workaround (some might call it an abuse of the system) -- you can have your Makefile.PL die with the message "OS unsupported". That will be detected by CPAN::Reporter or CPANPLUS and will cause your module to be graded "NA" instead of "FAIL".

But please come join the new cpan-testers-discuss mailing list and help us hash out a better approach. Email cpan-testers-discuss-subscribe@perl.org to join.

Update -- please note:

The "OS unsupported" answer is a hack and a bad one that pollutes the CPAN Testers database. "OS unsupported" should be reserved for a case where the module in question will never work on the platform in question. I don't want to encourage this since it's an easy enough case to fix in the CPAN Testers toolchain itself.

A third option is to simply ignore it. Everyone who clicks on the FAIL to see what happened will see the obviousness of the missing lib. I know I click them when I see them.

I like the Alien suggestion above though. I'm definitely using that in my own stuff at some point.

-Paul

I like the Alien suggestion above though. I'm definitely using that in my own stuff at some point.

Alien is only good if there is actually an Alien module for the library. E.g. Alien::wxWidgets or Alien::SVN. Otherwise, CPAN can never find and install the appropriate Alien module -- and thus your module can never satisfy its prerequisites and will not be installed unless forced.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

As a workaround (some might call it an abuse of the system) -- you can have your Makefile.PL die with the message "OS unsupported".

That's the sort of solution I was looking for. I think the element of abuse would be removed if CPAN::Reporter and CPANPLUS also searched for (something like) "System inadequate" ... or maybe there's a single phrase that caters for both scenarios.

But please come join the new cpan-testers-discuss mailing list and help us hash out a better approach

If that's the best way to get it sorted, then I'll do that. (Subscribing right now, but I might wait a day or two to see what else eventuates here before posting there.)

Thanks, as always, to *all* respondents.

Cheers,
Rob

It seems to me that adding another flag value ("dependency not met" sounds better/more neutral to me than "system inadequate") would be better than trying to find a single phrase that can cover both situations, because they are, IMO, fundamentally different.

Fixing a missing dependency (generally) only requires you to install it. Fixing an incorrect OS requires throwing out all of your existing software (and potentially most/all of your data with it) and replacing it with something else. Most people won't blink at installing a missing dependency, but few would change to a different OS just to use an unsupported module, so failures should report different results in each case.

Math::Pari has a companion in module Math::PariBuild, where the latter (unsurprisingly) is used during configuration of the former. Math::Pari depends on an underlying library (the PARI/GP library), and it actually attempts to download, compile and install the library, if not present during build.

Could that be an option for Math::MPC as well?

Could that be an option for Math::MPC as well?

I'm sure it could be made to work ... but it would create an added responsibility that I'm not (at this stage, anyway) prepared to take on. The mpc library itself needs the mpfr library, which in turn needs the gmp library ... seems to me that what you're suggesting could easily turn into a nightmare (especially if *I* am at the helm :-)

Cheers,
Rob

For anyone catching up on this thread later, let me point out that the experimental Devel::CheckLib is out and may be the solution to this problem eventually. See Devel::CheckLib: Please break our code! for more details.