so basically the executive summary is that cpanplus does not report
adequately system dependency failures, like a missing c compiler or a
missing library. i guess the issue is one of prioritizing an
appropriate response from maintainers who care about these reports.
specifically, maintainers of perl xs modules will likely not want to be
bothered with failure reports when the failure is due to a lack of a c
compiler.
here's my suggestions on what to do about it:
i like barbie's abstraction, so i'd add that to my outline of
CPAN/PLUS-yaml-ExtUtils::MakeMaker-Module::Build changes.
The idea is that perl xs modules have prereqs that are external to perl,
be they compilers, utilities, file naming conventions (to backslash or
not to backslash), libraries, etc. Failure in this regard is
essentially a prereq failure. ExtUtils::MakeMaker and M::B would be
changed to understand the concept of an external prereq. This external
prereq would be tested by a piece of custom code which the module author
would have to write, as I did with Compress::Bzip2 to test for the bzlib
library. Likely E::M and M::B would have a list of "names" of external
prereqs that would be understood, and reported on by the custom piece of
code. The yaml file generated by E::M and M::B would list these
external prereqs, by name and description. CPANPLUS understands perl
prereqs. external prereqs would be more difficult, but if we had a
naming convention some basic external prereqs could be preprepared since
they are everywhere, like for example system_cc=>"a c compiler",
system_libbz2=>"bzlib devel library". maybe something user_xxx=>"my
custom ext. prereq" for external prereqs requiring helper subroutines.
with perl xs, i just made CPANPLUS's check for prereqs more
complicated. E::M and M::B would have to assist in this. i think
currently cpanplus uses the yaml to check the prereqs and bails before
it even runs the .PL file, correct me if i'm wrong. ok then, both
scenarios. cpanplus runs .PL file and picks up prereq failures from the
logfile. this one is easy, the .PL file just has to report on the
external prereq failures. cpanplus reads the yaml and checks for
prereqs, and schedules perl prereqs for loading. for cpanplus to check
for external prereqs, with a naming convention there would be some
prereqs it could check for itself, but more generally it will have to
call the .PL file with some special options to make the .PL check the
prereqs. when invoked with those options, the .PL should not configure
the module. CPANPLUS would only call the .PL file with those options
(check external prereq) if the yaml indicated there were external
prereqs (backward compatibility).
external prereq failure of a critical component should cause cpanplus to
bail out of the build. unlike with perl prereqs, there is no recovery
action available to cpanplus. or, the .PL could supply a helper
function for recovery action. for example, in Compress::Bzip2 if there
is no bzlib installed, the recovery action is to activate the static
build of the internal bzlib tagalong. you could go crazy with this
one. like if a c compiler is missing you could fire up some p2p action
and download a c compiler and install it.
-rob
r w j a n e s a t r o g e r s . c o m
Robert Rothenberg wrote:
On 17/06/2005 09:14 Michael G Schwern wrote:
This is all a bit of a ramble. Could we have an executive summary as to
the point particularly in relation to MakeMaker, CPANPLUS and module
authors
in general?
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.
I'm of the opinion that people who pay attention to test reports when
deciding whether to use a module should be saavy enough to interpret
them, but I'm probably wrong. Maybe a FAQ is needed for the testers
web site that explains how to do this?
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.
Rob
--
Rob Janes
r w j a n e s a t r o g e r s . c o m
