On Aug 10, 2009, at 8:27 AM, David Golden wrote:
You might want to check out Devel::CheckLib as a tool for your
Makefile.PL
to check for the library and exit with a helpful error message when
the Makefile.PL is run.
On Sep 20, 2009, at 6:41 PM, David Golden wrote:
On Sun, Sep 20, 2009 at 8:51 PM, <cr...@animalhead.com> wrote:
1. Why are there so few test reports? Supposedly the prompt("
Please enter
path...")
which is provided by ExtUtils::MakeMaker, will not hang but
will sense
the smoky
environment and return the default from $libpath.
check_lib_or_exit will
then
report the problem in a way that will inform the tester of the
need for
the library.
Right?
Most automated smoke testing will just quietly exit and continue. The
testers will never see the prompt. This is generally how automated
testers like it (though there are exceptions). Stopping at every Nth
module to figure out how to resolve someone's custom dependency takes
extra time that donating some CPU cycles to the testing effort does
not.
The idea that you and http://wiki.cpantesters.org/wiki/CPANAuthorNotes
would recommend Devel::CheckLib as a means to handle a dependency on a
C library, and that the smoke testing SW does not pick up on its
output and tell the tester about the dependency, is slightly mind-
boggling.
OS assertions and check_lib_or_exit() are all just trying to make it
easier for authors to get quality reports. It's an arrangement
between testers and authors: if authors bail out in certain ways, then
testers won't hit the distribution with meaningless reports.
NOTE --> "exit 0" means that *no* report is sent. Not even an
UNKNOWN.
To me an UNKNOWN is a negative that may deter people from trying my
module.
So "no report" is the result I want ON CPAN if mm isn't available.
This is just like what happens with Perl prerequisites. If
a prerequisites can't be satisfied, then no report is sent.
2. Do you think the following start for Makefile.PL would lead to
more test
reports?
I think the most effective thing that will lead to more test reports
is asking people to install libmm-dev. That's best done via personal
appeal on the cpan-testers-discuss or on #cpantesters-discuss on
irc.perl.org. That means work for someone who maintains multiple
virtual machines, so ask nicely. ;-)
Nice isn't my strong suit, but I'll try. Thanks for the advice.
OBTW, I once got this reply from Oliver Paukstadt:
I use a module called Test::Warn
which you or some other tester did not have, and so several important
tests crashed before takeoff.
Automatic testing starts in a clean area to test dependencies for
example.
(I put Test::Warn in ExtUtils::MakeMaker's PREREQ_PM to fix that.)
But OP's comment made me imagine a highly automated and capable system
for detecting problems. How does an install resulting from a personal
appeal end up in "a clean area"?
Just for the record, I've installed it now and will attempt to send a
test report. What I've noticed so far is that some of the test files
are very slow and in other circumstances I might have hit CTRL-C by
now. You might want to warn( "# this test may take a long time to
finish\n") or something for the longer-running test files.
That sounds fishy. Here's the ending line from make test on my server:
Files=10, Tests=6744, 3 wallclock secs ( 1.12 usr 0.18 sys + 1.87
cusr 0.43 csys = 3.60 CPU)
Or is your CTRL-C finger really twitchy?
However, for the Makefile.PL itself, t would be much better to assume
that the library can be found and only prompt afterwards if it can't
be found: E.g.
use lib inc;
use Devel::AssertOS qw(Unix OS390 BeOS Cygwin);
use Devel::CheckLib;
use ExtUtils::MakeMaker;
eval { assert_lib( lib=> "mm" ) };
if ( $@ ) {
print "\nIPC::MMA requires the mm library, which is available" .
"at http://www.ossp.org/pkg/lib/mm/\n";;
$libpath = prompt(" Please enter path to libmm.so:", "/usr/
local/lib");
check_lib_or_exit( lib => 'mm', libpath => $libpath );
}
# Makefile.PL continues ...
That's much friendlier when I've used my system's package manager to
just install the package and it winds up in /usr/lib.
It shall be done that way in the next release. Thanks again!
3. If #2 is "yes" and I submit a new version with the above
Makefile.PL,
should I call it 0.59 or 0.58_01? There hasn't been a significant
change
to the module itself since 0.54.
Personally, if nothing has changed in the module itself since 0.54, I
probably would have numbered subsequent modules 0.54_01, 0.54_02, etc.
Given where you are now, I would use 0.58_01, 0.58_02, etc. It
indicates to anyone using your modules that you're just doing
development work and that they don't (necessarily) need to upgrade
just yet. The automated CPAN Testers will all test any distribution
you release, so the number doesn't matter.
Or putting it differently, if you're tweaking Makefile.PL and break
something, keeping it as an alpha release means you won't cause
problems for anyone who wants to install your module for non-testing
purposes.
The next release won't break anything. I got my new Makefile.PL code
from David Golden himself! :-)
On the flip side, I just found a new version of ExtUtils::ParseXS
(which I require to avoid certain false error messages), in which the
Changes file says:
2.200401 - Mon Sep 14 22:26:03 EDT 2009
- No changes from 2.20_04.
Which makes me feel like version number selection is like playing the
stock market. Which I'm also not good at...
Best Regards,
cmac
