On Fri, Jun 17, 2005 at 10:53:44AM +0100, Robert Rothenberg wrote:
> CPANPLUS issues FAIL reports when there is no C compiler, which irks
> module authors who feel such reports make their module look bad.
>
> Some feel that CPANPLUS should detect this and not send a report, others
> feel it should send a report, but with a different grade: NA or some new
> grade such as UNGRADED, since there are advantages to testing what a
> Build will do if there is no C compiler.
>
> Another idea is to ExtUtils::MakeMaker or Module::Build to refuse to try
> and build a module if a C compiler is required (and update CPANPLUS to
> detect this). This seems connected to the larger issue of NA reports
> when libraries or applications are missing.
Yes, this seems to be the way to go. Module::Build improves its external
dependency detection and reporting (it already has a lot of the
intrastructure to declare and detect external deps). The only change to
CPANPLUS is to better detect these new dep failures and act appropriately.
This both puts the responsibility onto the build system, which is better
set up to handle it, and improves error messages when you're installing a
module without CPANPLUS.
Right now the reporting seems a bit ad hoc so some discussion will have to
happen between the CPANPLUS folks and the MB folks.
The same work should be done on MakeMaker but it would be too broad (MakeMaker
has none of the existing detection and reporting tools) and introduce far
too much instability (because its make and shell, not Perl) too late in the
game. That part gets a resounding "no".
> My own take is that these fails should be sent out anyway, but as NA
> reports. Too many grade types can get confusing, but it should be
> feasible to analyze failure reports automatically to classify them:
> * Perl version too low
> * Unsupported operating system
> * Missing required libraries or applications
> * Missing compiler, linker or other utility needed for build
> * Other error during build
>
> In other words, the meaning of NA should be it wasn't able to
> successfully build the software and get to the testing phase.
No, that's not the meaning of NA. NA means "Not Applicable" which basically
means "Not the author's problem." Its for problems related to the user's
environment. This includes all of the above EXCEPT "other errors during
build". If the build craps out for an *unexpected* reason then it is now
the author's problem. Things such as:
* Syntax error
* Undeclared incompatibility
* Missing dependency
* Anything else the author didn't expect to fail
Take, for example, the recent problems PathTools was having on Windows which
caused a lot of build failures.
http://www.nntp.perl.org/group/perl.cpan.testers/180174
Those are legit failures during the build phase and should be reported.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <[EMAIL PROTECTED]>
