On May 15, 2009, at 11:11 AM, Smylers wrote:
I recently encountered a Cpan module which doesn't install from its
distribution yet passes all its tests, and I was wondering whether the
glitch is a generic one which should be addressed.
This particular module is not my concern (its maintainer responded
speedily and is now looking at fixing it), but it illustrates the
issue:
http://cpansearch.perl.org/src/JZAWODNY/DBIx-DWIW-0.49/
Note the module source is in the tarball at ./DBIx/DWIW.pm, and that
is
reflected in Makefile.PL. Running make creates the ./blib/lib/DBIx/
directory but doesn't copy the module to it (nor generate the
manpage).
It appears to work fine with the source at either ./DWIW.pm or
./lib/DBIx/DWIW.pm (and a corresponding Makefile.PL).
* Is this a known limitation of MakeMaker or a bug? If a bug then
I'll
report it. If a limitation, would it be possible for MakeMaker to
detect this condition and bail out (on both make dist and make),
rather than giving the impression it's succeeded?
It is documented in ExtUtils::MakeMaker
PMLIBDIRS
Ref to array of subdirectories containing library files. Defaults to
[ 'lib', $(BASEEXT) ]. The directories will be scanned and any files
they contain will be installed in the corresponding location in the
library. A libscan() method can be used to alter the behaviour.
Defining PM in the Makefile.PL will override PMLIBDIRS.
(Where BASEEXT is the last component of NAME.)
So for this modules it will scan lib/ and DWIW/ neither of which
exist. It also scans .
The install mapping for this module would be
foo.pm => DBIx/foo.pm
DWIW/bar.pm => DBIx/DWIW/bar.pm
lib/baz.pm => baz.pm
Graham.
