Front page | perl.perl5.porters |
Postings from February 2009
I've got MakeMaker mostly working sitting in ext/ExtUtils-MakeMaker in the
core. You can see it here.
http://github.com/schwern/perl/tree/ExtUtils-MakeMaker
The logic for copying ext/ExtUtils-MakeMaker/lib into lib/ is primitive and
isn't integrated into "make clean", but it's basically correct. MakeMaker is
kind of confused about being in a subdir of the Perl core, so it won't yet
build as a CPAN module, but I know how to fix that.
There's a MakeMaker test that fails because it doesn't expect $^X to be a
relative path and here we hit the snag. In order to normalize how tests are
run between CPAN and the core, each MakeMaker test has to include code like this:
BEGIN {
if( $ENV{PERL_CORE} ) {
unshift @INC, '../ext/ExtUtils-MakeMaker/t/lib';
}
else {
unshift @INC, 't/lib';
}
}
This is because the core runs tests in its own t/ but doing it CPAN-style
would mean running them in ext/ExtUtils-MakeMaker/ So if I want to include
t/lib in @INC I have to include scaffolding like the above and always remember
that the tests might be running from an odd location.
This is annoying and really its unnecessary. The point of putting non-XS
modules into ext/ is to reduce the differences between the CPAN and core
versions. This goes both ways. The core is currently cheating in how it runs
ext/ tests, it's running them manually rather than using "make test".
So I propose changing how the core runs the ext/ tests. Rather than running
them as part of one large run, let's take advantage of make and just let "make
test" cascade down into the ext/ directories. The t/ and lib/ tests would run
first, then "make test" would be run in each ext/ directory.
Thoughts? I'm going to go hack on that.
--
Hating the web since 1994.
Thread Next