Thread: [Module::Build] Module::Build 0.27_09 -> CPAN
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Ken W. <ke...@ma...> - 2006-03-12 04:04:29
|
Hi,
I've just released M::B 0.27_09 with the following changes. In
particular, when I use this copy of Module/Build.pm in bleadperl, all
the M::B-related tests now pass (though with considerable complaining).
0.27_09 Sat Mar 11 22:48:54 EST 2006
- Fixed find_perl_interpreter() so we can find the perl executable
when running from uninstalled perl even when $^X contains a
relative path. [Yitzchak Scott-Thoennes]
- Fixed warning message where we were printing the wrong field names.
[Chris Dolan]
- Added a 'testpodcoverage' action that runs a POD coverage check for
all modules in the distribution. [Yanick Champoux]
- Added a Cookbook example of subclassing to modify an action. [Dylan
Martin and David Golden]
- When building HTML documentation, we were opening the POD file and
not checking whether the open succeeded, which of course caused
problems down the line if it failed. Now we do "or die(...)" like
everywhere else. [Spotted by Joerg Braun]
-Ken
|
|
From: Randy W. S. <ml...@th...> - 2006-03-12 08:02:21
Attachments:
mb-bleed.patch
|
Ken Williams wrote: > Hi, > > I've just released M::B 0.27_09 with the following changes. In > particular, when I use this copy of Module/Build.pm in bleadperl, all > the M::B-related tests now pass (though with considerable complaining). > > > 0.27_09 Sat Mar 11 22:48:54 EST 2006 Attached is a patch against bleed. Randy. |
|
From: Andy D. <dou...@la...> - 2006-03-14 01:32:15
|
> > Ken Williams wrote:
> > >I've just released M::B 0.27_09 with the following changes. In
> > >particular, when I use this copy of Module/Build.pm in bleadperl, all
> > >the M::B-related tests now pass (though with considerable complaining).
Alas, this still fails for me. I build perl on Solaris with a symlink tree
sh ../perl-current/Configure -Dmksymlinks -Dprefix=/tmp/perl -des
and the Module Build tests still fail. Here's a sample:
../lib/Module/Build/t/basic..................................Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
BEGIN failed--compilation aborted.
Use of uninitialized value $perl in concatenation (.) or string at /home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line 1162.
sh: -le: not found
Here's another sample:
../lib/Module/Build/t/ext....................................PERL_CORE is set but I can't find your perl source!
Bareword "our" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
Bareword "Config" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
Operator or semicolon missing before %Config at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
Ambiguous use of % resolved as operator % at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21.
BEGIN not safe after errors--compilation aborted at /home/doughera/src/perl/perl-andy/lib/Config.pm line 31.
BEGIN failed--compilation aborted.
I think the other error messages here are because the test apparently
picked up an older perl (probably 5.00503) installed elsewhere in my
PATH.
Strangely enough, despite those failures, the test_harness target still
reported all tests successful:
All tests successful (5 subtests UNEXPECTEDLY SUCCEEDED), 63 tests and 323 subtests skipped.
--
Andy Dougherty dou...@la...
|
|
From: Randy W. S. <ml...@th...> - 2006-03-14 02:02:54
Attachments:
findperl.diff
|
Andy Dougherty wrote: >>> Ken Williams wrote: > >>>> I've just released M::B 0.27_09 with the following changes. In >>>> particular, when I use this copy of Module/Build.pm in bleadperl, all >>>> the M::B-related tests now pass (though with considerable complaining). > > Alas, this still fails for me. I build perl on Solaris with a symlink tree > > sh ../perl-current/Configure -Dmksymlinks -Dprefix=/tmp/perl -des > > and the Module Build tests still fail. Here's a sample: > > ../lib/Module/Build/t/basic..................................Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .). > BEGIN failed--compilation aborted. > Use of uninitialized value $perl in concatenation (.) or string at /home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line 1162. > sh: -le: not found > > Here's another sample: > > ../lib/Module/Build/t/ext....................................PERL_CORE is set but I can't find your perl source! > Bareword "our" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21. > Bareword "Config" not allowed while "strict subs" in use at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21. > Operator or semicolon missing before %Config at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21. > Ambiguous use of % resolved as operator % at /home/doughera/src/perl/perl-andy/lib/Config.pm line 21. > BEGIN not safe after errors--compilation aborted at /home/doughera/src/perl/perl-andy/lib/Config.pm line 31. > BEGIN failed--compilation aborted. > > I think the other error messages here are because the test apparently > picked up an older perl (probably 5.00503) installed elsewhere in my > PATH. This is what happens. It looks at several potential perls, and for each one, compares the configuration to see if it's the same perl that is currently executing. The problem is that when it executes the perl binary it finds in the core, it doesn't pass in the correct include directory for it to find Config.pm, so the test fails and it continues the search by looking in the PATH. Attached is a working (not final) patch that works for me on FreeBSD, Ubuntu Linux, Windows XP, and cygwin. Could you please give it a spin? Thanks, Randy. > Strangely enough, despite those failures, the test_harness target still > reported all tests successful: > > All tests successful (5 subtests UNEXPECTEDLY SUCCEEDED), 63 tests and 323 subtests skipped. > |
|
From: Dominic D. <sho...@ma...> - 2006-03-14 09:06:07
|
On 2006=9603=9614, at 03:02, Randy W. Sims wrote: > Attached is a working (not final) patch that works for me on =20 > FreeBSD, Ubuntu Linux, Windows XP, and cygwin. Could you please =20 > give it a spin? Also results in all tests passing on Mac OS X. Thanks! $ ./TEST ../lib/Module/Build/t/*.t t/../lib/Module/Build/t/basic...........ok t/../lib/Module/Build/t/compat..........ok t/../lib/Module/Build/t/destinations....ok t/../lib/Module/Build/t/ext.............ok t/../lib/Module/Build/t/extend..........ok t/../lib/Module/Build/t/files...........ok t/../lib/Module/Build/t/install.........ok t/../lib/Module/Build/t/manifypods......ok t/../lib/Module/Build/t/metadata........ok t/../lib/Module/Build/t/metadata2.......ok t/../lib/Module/Build/t/moduleinfo......ok t/../lib/Module/Build/t/notes...........ok t/../lib/Module/Build/t/parents.........ok t/../lib/Module/Build/t/pod_parser......ok t/../lib/Module/Build/t/ppm.............ok t/../lib/Module/Build/t/runthrough......ok t/../lib/Module/Build/t/signature.......skipping test on this platform t/../lib/Module/Build/t/tilde...........ok t/../lib/Module/Build/t/versions........ok t/../lib/Module/Build/t/xs..............ok All tests successful. u=3D0.24 s=3D0.11 cu=3D91.17 cs=3D50.73 scripts=3D19 tests=3D663 (That was a threaded bleadperl@27491.) Previously, there had been two failures: lib/Module/Build/t/ext.....................................PERL_CORE =20 is set but I can't find your perl source! Perl lib version (5.9.4) doesn't match executable version (v5.8.6) =20 at /Volumes/Tottie/Other/src/Perl/perl-current-working/lib/Config.pm =20 line 46. Compilation failed in require. BEGIN failed--compilation aborted. Perl lib version (5.9.4) doesn't match executable version (v5.8.6) =20 at /Volumes/Tottie/Other/src/Perl/perl-current-working/lib/Config.pm =20 line 46. Compilation failed in require. BEGIN failed--compilation aborted. PERL_CORE is set but I can't find your perl source! Use of uninitialized value $perl in concatenation (.) or string at /=20 Volumes/Tottie/Other/src/Perl/perl-current-working/t/../lib/Module/=20 Build/Base.pm line 1162. sh: - : invalid option Use of uninitialized value $cmd[0] in join or string at /Volumes/=20 Tottie/Other/src/Perl/perl-current-working/t/../lib/Module/Build/=20 Base.pm line 3726. Use of uninitialized value $cmd[0] in system at /Volumes/Tottie/Other/=20= src/Perl/perl-current-working/t/../lib/Module/Build/Base.pm line 3727. Can't exec "": No such file or directory at /Volumes/Tottie/Other/src/=20= Perl/perl-current-working/t/../lib/Module/Build/Base.pm line 3727. # Failed test in ../lib/Module/Build/t/ext.t at line 100. # ' -le print for @INC # ' # doesn't match '(?m-xis:^whosiewhatzit)' # Looks like you failed 1 test of 92. FAILED at test 92 ... lib/Module/Build/t/compat..................................sh: - : =20 invalid option Couldn't run Build.PL: No such file or directory at /Volumes/Tottie/=20 Other/src/Perl/perl-current-working/t/../lib/Module/Build/Compat.pm =20 line 199. # Failed test in ../lib/Module/Build/t/compat.t at line 180. # Failed test 'Makefile should exist' # in ../lib/Module/Build/t/compat.t at line 181. make[3]: *** No targets specified and no makefile found. Stop. FAILED at test 3 and vast numbers of "uninitialized value" warnings, even when tests =20 passed. --=20 Dominic Dunlop |
|
From: Dominic D. <sho...@ma...> - 2006-03-18 12:46:34
Attachments:
M-B@27533_MacOSX_failures.bz2
|
On 2006=9603=9614, at 03:02, Randy W. Sims wrote: > Attached is a working (not final) patch that works for me on =20 > FreeBSD, Ubuntu Linux, Windows XP, and cygwin. Could you please =20 > give it a spin? How's this getting along? Even though change 27531, Upgrade to =20 ExtUtils::CBuilder 0.17, cuts the number of failures on Mac OS X from =20= seven to two, testing still produces a vast number of warnings -- see =20= the attached file. The provisional patch you posted in the mail I'm replying to had a =20 better effect, making all tests pass and suppressing all warnings. --=20 Dominic Dunlop |
|
From: Randy W. S. <ml...@th...> - 2006-03-20 11:24:57
|
Dominic Dunlop wrote: > On 2006–03–14, at 03:02, Randy W. Sims wrote: > >> Attached is a working (not final) patch that works for me on FreeBSD, >> Ubuntu Linux, Windows XP, and cygwin. Could you please give it a spin? > > > How's this getting along? Even though change 27531, Upgrade to > ExtUtils::CBuilder 0.17, cuts the number of failures on Mac OS X from > seven to two, testing still produces a vast number of warnings -- see > the attached file. > > The provisional patch you posted in the mail I'm replying to had a > better effect, making all tests pass and suppressing all warnings. The update to EU::CBuilder provided only part of the fix. We do have a fix in cvs for the other failures related to Module::Build on BSD. There are a couple of other things that I need to fix: some warnings from Archive::Tar, failures on Windows when using Borland compiler, and I also need to check MinGW on Windows... Randy. |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-15 18:24:18
|
On Sun, Mar 12, 2006 at 12:15:40PM -0600, Steve Peters wrote: > On Sun, Mar 12, 2006 at 03:01:29AM -0500, Randy W. Sims wrote: > > Ken Williams wrote: > > >Hi, > > > > > >I've just released M::B 0.27_09 with the following changes. In > > >particular, when I use this copy of Module/Build.pm in bleadperl, all > > >the M::B-related tests now pass (though with considerable complaining). > > > > > > > > >0.27_09 Sat Mar 11 22:48:54 EST 2006 > > > > Attached is a patch against bleed. > > > > Randy, > > Actually, I patched Module::Build before I read your email, but thanks > anyways :) > > Module::Build was updated in bleadperl with change #27841. Steve, Randy, I'm almost certain there is no difference this time around, but for the future, please note that bleadperl contains the Module/Build/ConfigData.pm which you have to generate (run Build.PL and Build on the CPAN dist and pull it out of blib/). |
|
From: Ken W. <ke...@ma...> - 2006-03-14 02:39:33
|
On Mar 13, 2006, at 8:02 PM, Randy W. Sims wrote: > This is what happens. It looks at several potential perls, and for > each one, compares the configuration to see if it's the same perl > that is currently executing. The problem is that when it executes > the perl binary it finds in the core, it doesn't pass in the > correct include directory for it to find Config.pm, so the test > fails and it continues the search by looking in the PATH. I have a little theory that in some cases it's actually the reverse - our @INC is set to find modules in the not-yet-installed perl (otherwise no modules would be able to load, and they do load), but we're testing out other perls and *they* can't find an appropriate Config.pm. Or in general: if our @INC is inappropriate to the perls we're testing, then we'll see this kind of behavior. Maybe there's a way to short-circuit early? Compare 'perl -v' before comparing 'Config- >myconfig' perhaps? -Ken |
|
From: Andy D. <dou...@la...> - 2006-03-14 04:30:39
|
On Mon, 13 Mar 2006, Ken Williams wrote:
>
> On Mar 13, 2006, at 8:02 PM, Randy W. Sims wrote:
>
> > This is what happens. It looks at several potential perls, and for each one,
> > compares the configuration to see if it's the same perl that is currently
> > executing. The problem is that when it executes the perl binary it finds in
> > the core, it doesn't pass in the correct include directory for it to find
> > Config.pm, so the test fails and it continues the search by looking in the
> > PATH.
>
> I have a little theory that in some cases it's actually the reverse - our @INC
> is set to find modules in the not-yet-installed perl (otherwise no modules
> would be able to load, and they do load), but we're testing out other perls
> and *they* can't find an appropriate Config.pm.
Yes, in some cases it's the reverse. In the first error message I posted,
it's the just-built perl that's complaining. In the second error message,
it's an old perl5.00503.
I'm happy to report that in both cases, however, Randy's patch works!
Thanks!
--
Andy Dougherty dou...@la...
|
|
From: Randy W. S. <ml...@th...> - 2006-03-14 11:05:17
|
Andy Dougherty wrote: > On Mon, 13 Mar 2006, Ken Williams wrote: > > >>On Mar 13, 2006, at 8:02 PM, Randy W. Sims wrote: >> >> >>>This is what happens. It looks at several potential perls, and for each one, >>>compares the configuration to see if it's the same perl that is currently >>>executing. The problem is that when it executes the perl binary it finds in >>>the core, it doesn't pass in the correct include directory for it to find >>>Config.pm, so the test fails and it continues the search by looking in the >>>PATH. >> >>I have a little theory that in some cases it's actually the reverse - our @INC >>is set to find modules in the not-yet-installed perl (otherwise no modules >>would be able to load, and they do load), but we're testing out other perls >>and *they* can't find an appropriate Config.pm. > > > Yes, in some cases it's the reverse. In the first error message I posted, > it's the just-built perl that's complaining. In the second error message, > it's an old perl5.00503. > > I'm happy to report that in both cases, however, Randy's patch works! > > Thanks! > Attached are my final suggested patches for MB & EUCB. Note that I've restricted the search for the perl interpreter so that it does not search in the PATH if PERL_CORE is set as I believe this is more correct. In practice this has no effect on any system I've tested on because we always find it where we expect now. Also, find_perl_interpreter now throws an exception if it fails. If this is sensible I can check it in and generate a patch for blead. Randy. |
|
From: Ken W. <ke...@ma...> - 2006-03-14 23:50:30
|
Hi Randy,
I think the find_perl_interpreter() and perl_is_same() methods are
getting uglier and uglier (i.e. they're getting more special-casing),
which is just fine as long as they work, but I think I'm going to
want to clean them up at some point. Which means we need to have
tests that will exercise the various cases we're covering, or else
I'll probably break something.
I know that's going to pretty hard to do, but maybe a first step
would be just to list the specific cases we indeed cover, right in
the corresponding code.
I say go ahead and check this in to fix breakage, and let's try to
fairly quickly (before we forget) add those comments.
-Ken
On Mar 14, 2006, at 5:04 AM, Randy W. Sims wrote:
> Attached are my final suggested patches for MB & EUCB.
>
> Note that I've restricted the search for the perl interpreter so
> that it does not search in the PATH if PERL_CORE is set as I
> believe this is more correct. In practice this has no effect on any
> system I've tested on because we always find it where we expect now.
>
> Also, find_perl_interpreter now throws an exception if it fails.
>
> If this is sensible I can check it in and generate a patch for blead.
>
> Randy.
> Index: lib/ExtUtils/CBuilder/Base.pm
> ===================================================================
> RCS file: /cvsroot/module-build/ExtUtils-CBuilder/lib/ExtUtils/
> CBuilder/Base.pm,v
> retrieving revision 1.19
> diff -u -r1.19 Base.pm
> --- lib/ExtUtils/CBuilder/Base.pm 3 Oct 2005 22:05:14 -0000 1.19
> +++ lib/ExtUtils/CBuilder/Base.pm 14 Mar 2006 10:51:19 -0000
> @@ -240,11 +240,11 @@
>
> return unless $ENV{PERL_CORE};
>
> - my $Updir = File::Spec->updir;
> - my $dir = $Updir;
> + my $Updir = File::Spec->updir;
> + my $dir = File::Spec->curdir;
>
> # Try up to 5 levels upwards
> - for (1..5) {
> + for (0..5) {
> if (
> -f File::Spec->catfile($dir,"config_h.SH")
> &&
> @@ -257,9 +257,9 @@
>
> $dir = File::Spec->catdir($dir, $Updir);
> }
> -
> +
> warn "PERL_CORE is set but I can't find your perl source!\n";
> - return;
> + return ''; # return empty string if $ENV{PERL_CORE} but can't
> find dir ???
> }
>
> # directory of perl's include files
> Index: lib/Module/Build/Base.pm
> ===================================================================
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/
> Base.pm,v
> retrieving revision 1.558
> diff -u -r1.558 Base.pm
> --- lib/Module/Build/Base.pm 11 Mar 2006 03:06:20 -0000 1.558
> +++ lib/Module/Build/Base.pm 14 Mar 2006 10:50:37 -0000
> @@ -12,7 +12,6 @@
> use Data::Dumper ();
> use IO::File ();
> use Text::ParseWords ();
> -use Carp ();
>
> use Module::Build::ModuleInfo;
> use Module::Build::Notes;
> @@ -317,37 +316,67 @@
>
> sub _perl_is_same {
> my ($self, $perl) = @_;
> - return `$perl -MConfig=myconfig -e print -e myconfig` eq Config-
> >myconfig;
> +
> + my $INC = '';
> + if ($ENV{PERL_CORE}) {
> + $INC = '-I' . File::Spec->catdir(File::Basename::dirname
> ($perl), 'lib');
> + }
> +
> + return `$perl $INC -MConfig=myconfig -e print -e myconfig` eq
> Config->myconfig;
> }
>
> sub find_perl_interpreter {
> - return $^X if File::Spec->file_name_is_absolute($^X);
> my $proto = shift;
> - my $c = ref($proto) ? $proto->config : \%Config::Config;
> - my $exe = $c->{exe_ext};
> + my $c = ref($proto) ? $proto->config : \%Config::Config;
>
> - my $thisperl = $^X;
> - if ($proto->os_type eq 'VMS') {
> - # VMS might have a file version at the end
> - $thisperl .= $exe unless $thisperl =~ m/$exe(;\d+)?$/i;
> - } elsif (defined $exe) {
> - $thisperl .= $exe unless $thisperl =~ m/$exe$/i;
> - }
> + my @potential_perls;
> +
> + my $perl = $^X;
> + push( @potential_perls, $perl )
> + if File::Spec->file_name_is_absolute($perl);
> +
> + my $abs_perl = File::Spec->rel2abs($perl);
> + push( @potential_perls, $abs_perl );
> +
> + my $perl_basename = File::Basename::basename($perl);
>
> - my $uninstperl;
> if ($ENV{PERL_CORE}) {
> +
> # CBuilder is also in the core, so it should be available here
> require ExtUtils::CBuilder;
> - $uninstperl = File::Spec->catfile(ExtUtils::CBuilder::-
> >perl_src, $thisperl);
> + my $perl_src = ExtUtils::CBuilder->perl_src;
> + if ( defined($perl_src) && length($perl_src) ) {
> + my $uninstperl =
> + File::Spec->rel2abs(File::Spec->catfile( $perl_src,
> $perl_basename ));
> + push( @potential_perls, $uninstperl );
> + }
> +
> + } else {
> +
> + push( @potential_perls, $c->{perlpath} );
> +
> + push( @potential_perls,
> + map File::Spec->catfile($_, $perl_basename), File::Spec-
> >path() );
> }
>
> - foreach my $perl ( $uninstperl || (),
> - $c->{perlpath},
> - map File::Spec->catfile($_, $thisperl), File::Spec->path()
> - ) {
> - return $perl if -f $perl and $proto->_perl_is_same($perl);
> + my $exe = $c->{exe_ext};
> + foreach my $thisperl ( @potential_perls ) {
> +
> + if ($proto->os_type eq 'VMS') {
> + # VMS might have a file version at the end
> + $thisperl .= $exe unless $thisperl =~ m/$exe(;\d+)?$/i;
> + } elsif (defined $exe) {
> + $thisperl .= $exe unless $thisperl =~ m/$exe$/i;
> + }
> +
> + if ( -f $thisperl && $proto->_perl_is_same($thisperl) ) {
> + return $thisperl;
> + }
> }
> - return;
> +
> + my @paths = map File::Basename::dirname($_), @potential_perls;
> + die "Can't locate the perl binary used to run this script " .
> + "in (@paths)\n";
> }
>
> sub _is_interactive {
> @@ -1235,8 +1264,7 @@
> use $build_package;
>
> # Some platforms have problems setting \$^X in shebang contexts,
> fix it up here
> -\$^X = Module::Build->find_perl_interpreter
> - unless File::Spec->file_name_is_absolute(\$^X);
> +\$^X = Module::Build->find_perl_interpreter;
>
> if (-e 'Build.PL' and not $build_package->up_to_date('Build.PL', \
> $progname)) {
> warn "Warning: Build.PL has been altered. You may need to run
> 'perl Build.PL' again.\\n";
|
|
From: Randy W. S. <ml...@th...> - 2006-03-15 02:31:07
|
Ken Williams wrote: > Hi Randy, > > I think the find_perl_interpreter() and perl_is_same() methods are > getting uglier and uglier (i.e. they're getting more special-casing), > which is just fine as long as they work, but I think I'm going to want > to clean them up at some point. Which means we need to have tests that > will exercise the various cases we're covering, or else I'll probably > break something. > > I know that's going to pretty hard to do, but maybe a first step would > be just to list the specific cases we indeed cover, right in the > corresponding code. > > I say go ahead and check this in to fix breakage, and let's try to > fairly quickly (before we forget) add those comments. Added with copious comments. I'm not sure how you want to handle release. There really isn't anything to justify a CPAN release. Should we just generate a patch against blead? Then wait for more the smokes to clear before making an actual release? Randy. |
|
From: Ken W. <ke...@ma...> - 2006-03-20 13:23:30
|
On Mar 20, 2006, at 5:23 AM, Randy W. Sims wrote: > > The update to EU::CBuilder provided only part of the fix. We do > have a fix in cvs for the other failures related to Module::Build > on BSD. There are a couple of other things that I need to fix: some > warnings from Archive::Tar, failures on Windows when using Borland > compiler, and I also need to check MinGW on Windows... We probably shouldn't worry too much about Archive::Tar just yet, it's producing a few failures of its own in blead on OS X, so it's probably a moving target. -Ken |
|
From: Andy D. <dou...@la...> - 2006-03-20 18:18:19
|
On Mon, 20 Mar 2006, Ken Williams wrote:
>
> On Mar 20, 2006, at 5:23 AM, Randy W. Sims wrote:
> >
> > The update to EU::CBuilder provided only part of the fix. We do have a fix
> > in cvs for the other failures related to Module::Build on BSD. There are a
> > couple of other things that I need to fix: some warnings from Archive::Tar,
> > failures on Windows when using Borland compiler, and I also need to check
> > MinGW on Windows...
>
>
> We probably shouldn't worry too much about Archive::Tar just yet, it's
> producing a few failures of its own in blead on OS X, so it's probably a
> moving target.
As of today, I'm still getting a number of failures, all of the form
../lib/Module/Build/t/basic..................................Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
BEGIN failed--compilation aborted.
Use of uninitialized value $perl in concatenation (.) or string at /home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line 1162.
sh: -le: not found
ok
What's perhaps equally distressing is that despite these failures,
t/harness still reports "All tests successful":
All tests successful (5 subtests UNEXPECTEDLY SUCCEEDED), 63 tests and 315 subtests skipped.
Files=1227, Tests=163911, 6437 wallclock secs (2076.56 cusr + 343.13 csys = 2419.69 CPU)
This also means that my previous report that Randy's patch worked may not
have been entirely correct -- this failure may still have been present,
but since it slips through the test harness, I might not have noticed it.
Lastly, here's a bit more verbosity on where it goes wrong.
Specifically, only the tests where it runs ../../../perl Makefile.PL seem
to fail. Again, the problem is @INC is looking for the not-yet-installed
perl.
../lib/Module/Build/t/compat....1..60
ok 1
Warning: Removing existing directory '/home/doughera/src/perl/perl-andy/t/_tmp/Simple'
Checking whether your kit is complete...
Looks good
Checking prerequisites...
Looks good
Creating new 'Build' script for 'Simple' version '0.01'
ok 2
../../../perl Makefile.PL
# running Build.PL
Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
BEGIN failed--compilation aborted.
sh: -le: not found
./../../../perl Build.PL
Checking whether your kit is complete...
Looks good
Checking prerequisites...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Simple' version '0.01'
ok 3
--
Andy Dougherty dou...@la...
|
|
From: Ken W. <ke...@ma...> - 2006-03-20 21:16:56
|
On Mar 20, 2006, at 12:18 PM, Andy Dougherty wrote: > On Mon, 20 Mar 2006, Ken Williams wrote: > >> >> On Mar 20, 2006, at 5:23 AM, Randy W. Sims wrote: >>> >>> The update to EU::CBuilder provided only part of the fix. We do >>> have a fix >>> in cvs for the other failures related to Module::Build on BSD. >>> There are a >>> couple of other things that I need to fix: some warnings from >>> Archive::Tar, >>> failures on Windows when using Borland compiler, and I also need >>> to check >>> MinGW on Windows... >> >> >> We probably shouldn't worry too much about Archive::Tar just yet, >> it's >> producing a few failures of its own in blead on OS X, so it's >> probably a >> moving target. > > As of today, I'm still getting a number of failures, all of the form > > ../lib/Module/Build/t/basic..................................Can't > locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4- > solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4- > solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .). > BEGIN failed--compilation aborted. > Use of uninitialized value $perl in concatenation (.) or string at / > home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line > 1162. > sh: -le: not found > ok > > What's perhaps equally distressing is that despite these failures, > t/harness still reports "All tests successful": > It's actually telling the truth - all those "failures" are happening when it's poking around your disk looking for the right perl executable, and sometimes that produces a lot of noise. It simply moves on and eventually finds the right one, and thus eventually succeeds. We've got patches in the pipeline to help a lot with this, but they're not applied yet pending some fact-finding about them. -Ken |
Thanks for helping keep SourceForge clean.
X