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.
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. 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. ;-)
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.
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.
> 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.
Regards,
David
