request for comments on code for ExtUtils::MY overrides

[David Christensen]

***@perl.org:

I've been using ExtUtils::MakeMaker for many years, it works well, and I
like it. I've heard of Module::Install and Module::Build, but I'm of
the mind "if it ain't broke, don't fix it".


About a year ago, I wanted to add some targets and rules to the Makefile
generated by ExtUtils::MakeMaker::WriteMakefile() and I wanted to
collect together some favorite test scripts. So, I STFW, RTFM, looked
in books, etc., and came up with this:

http://search.cpan.org/~dpchrist/Dpchrist-Module-1.026/


Recently, I've been using CPAN testers to help squash the bugs:

http://www.cpantesters.org/distro/D/Dpchrist-Module.html


So far, so good. But, I know there are still issues:

1. By mixing two kinds of things in one module (overrides for
ExtUtils::MY and favorite test scripts), the overall distribution name
was a compromise.

2. I am worried that by blindly stepping on the MY::postamble()
subroutine, I will break other modules that also use it
(ExtUtils::MakeMaker::Coverage?).

3. Some of the command-line tools invoked use GNU/Linux absolute paths.

4. The distribution contains two modules, and some CPAN tester systems
get confused:

http://www.cpantesters.org/cpan/report/1a09554e-fb48-11df-bb29-ad544afd17af


So, I've:

1. Split the old module into two new modules:

Dpchrist::ExtUtils::MakeMaker
Dpchrist::Test

2. Figured out how to daisy-chain MY::postamble() calls.

3. Changed tool invocations to basename only.

4. Ensured that there is only one *.pm file in each new module.


I would appreciate any comments, criticisms, suggestions, etc., on the
attached modules. (Dpchrist::Test uses Dpchrist::ExtUtils::MakeMaker,
and vice versa.)


David

[David Christensen]

makemaker:

I've uploaded the tarballs here:

http://holgerdanske.com/node/485


This is what I'm thinking for the next iteration of
Dpchrist::ExtUtils::MakeMaker:

=head1 SYNOPSIS

# Makefile.PL
package Dpchrist::ExtUtils::MakeMaker; # to find symbols
use strict;
use warnings;
eval {
require Dpchrist::ExtUtils::MakeMaker;
import Dpchrist::ExtUtils::MakeMaker (
postamble => sub {
my $prev_text = shift; # previous override, if any
return join("\n",
$prev_text,
mcpani($ENV{CPAN_AUTHORID}),
pod2html('lib/Dpchrist/ExtUtils/MakeMaker.pm'),
readme('lib/Dpchrist/ExtUtils/MakeMaker.pm'),
release($ENV{RELEASE_ROOT}),
);
},
);
};
warn $@ if $@;


=head3 import

# Makefile.PL
package Dpchrist::ExtUtils::MakeMaker; # to find symbols
use strict;
use warnings;
eval {
require Dpchrist::ExtUtils::MakeMaker;
import Dpchrist::ExtUtils::MakeMaker (
SECTION => CODEREF,
SECTION => CODEREF,
SECTION => CODEREF,
);
};
warn $@ if $@;

Daisy-chains subroutine CODEREF
into the Makefile override for given SECTION.
Any previous override function (e.g. &MY::SECTION)
will be called before CODEREF
and it's output passed as the first argument to CODEREF.
CODEREF should return a scalar string containing
the net text to be placed in the appropriate Makefile section.


Any comments?


David

[David Christensen]

makemaker:


I reworked Dpchrist::ExtUtils::MakeMaker and Dpchrist::Test to better
fit the ExtUtils::MY override scheme (as best as I can figure it out):

SYNOPSIS

# Makefile.PL

package Dpchrist::ExtUtils::MakeMaker; # for symbols

use ExtUtils::MakeMaker;

eval {
require Dpchrist::ExtUtils::MakeMaker;
import Dpchrist::ExtUtils::MakeMaker (
postamble => sub {
my ($o, $prev) = @_;
return join('',
$prev,
mcpani( $o, $ENV{CPAN_AUTHORID}),
pod2html($o, 'lib/Dpchrist/ExtUtils/MakeMaker.pm'),
readme( $o, 'lib/Dpchrist/ExtUtils/MakeMaker.pm'),
release( $o, $ENV{RELEASE_ROOT}),
);
},
);
};
warn $@ if $@;

WriteMakefile(
# ...
);


New tarballs are here:

http://holgerdanske.com/node/485


I would welcome any comments.


TIA,

David