Thread: Re: [Module::Build] Re: [PATCH] add Module::Build 0.27_08 (Page 2)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Ken W. <ke...@ma...> - 2006-03-12 03:29:06
|
On Mar 9, 2006, at 4:53 AM, Paul Marquess wrote: > > The patch to C::Z earlier this week moved a pile of files around. > If you > didn't specify the "--delete" option when you rsync the blead you > end up > with multiple copies of some of these files. Thanks for letting me know. My rsync fu wasn't strong enough to get --delete to work, but just deleting that part of the file tree and resyncing did the trick. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-03-09 02:50:14
|
On Mar 8, 2006, at 7:24 PM, Ken Williams wrote: > > On Mar 8, 2006, at 2:50 AM, Dominic Dunlop wrote: > >> On 2006=9603=9607, at 21:37, Randy W. Sims wrote: >> >>> Unfortunately, I don't have a broken system to test on so I'm =20 >>> mostly guessing. I do have an old 633 Mhz Pentium PC laying =20 >>> around somewhere that I can install one of the BSD variant on =20 >>> tonight or tomorrow. >> >> That looks like the way to go, as I can't guarantee to respond =20 >> quickly when asked to run tests -- and I don't know the code =20 >> anyway. Good luck with that install. Alternatively, does anybody =20 >> on the M::B list have a Mac with some version of Mac OS X on it =20 >> lying around? > > My main machine (powerbook) runs OS X 10.4.something. Obviously =20 > M::B's tests pass for me in its standalone distro, I'll try testing =20= > blead. Right now blead is failing to build for me though, because =20 > it's missing a constants.xs file for Compress::Zlib or something. =20 > I'll try to get creative with symlinks. OK, I got blead to build and now I do indeed see M::B failures in =20 testing. The errors are indeed in find_perl_interpreter(), because =20 if I change it to always return the constant value of my bleadperl's =20 perl, tests start passing. I'll investigate a fix. -Ken |
|
From: Ken W. <ke...@ma...> - 2006-03-09 03:02:05
|
On Mar 8, 2006, at 8:50 PM, Ken Williams wrote:
> OK, I got blead to build and now I do indeed see M::B failures in
> testing. The errors are indeed in find_perl_interpreter(), because
> if I change it to always return the constant value of my
> bleadperl's perl, tests start passing.
>
> I'll investigate a fix.
So I've finally grasped the problem - probably I'm the last person
to. What's happening is that $^X is relative ('./perl'), and then we
chdir('_tmp/Simple') so perl can't be found anymore.
I think we either need to explicitly tell M::B where perl is in this
situation (e.g. by doing find_perl_interpreter() before chdir() and
passing the subbuild the complete path), or avoid the chdir() in the
first place.
Either of those would be preferable to the guessing game of trying './
perl' and '../perl' and '../../perl' and so on, but of course that
would be the quickest band-aid.
-Ken
|
|
From: Randy W. S. <ml...@th...> - 2006-03-13 12:15:46
Attachments:
findperl.diff
|
Randy W. Sims wrote:
> Unfortunately, I don't have a broken system to test on so I'm mostly
> guessing. I do have an old 633 Mhz Pentium PC laying around somewhere
> that I can install one of the BSD variant on tonight or tomorrow.
I've been taking my time getting my BSD test system up because I was
assuming from previous reports that the BSD issue was mostly fixed. I
finally got it up and configured enough to do some testing, and it looks
like there are still failures because of the same issue, mostly.
The attached patch is my rough working code to get it fixed.
Module::Build::Base::_perl_is_same needs to set @INC in order to find
Config.pm when $ENV{PERL_CORE}. Is there a better alternative?
ExtUtils::CBuilder::Base::perl_src needs to check in the current
directory before moving up. Well, maybe. This really is just a result of
the way I rewrote Module::Build::Base::find_perl_interpreter to collect
a list of /all/ candidates before testing for the correct one. If $perl
and $abs_perl where tested and successful, we could return before the
call to perl_src(). It's not really a problem except for the spurious
warning about not find the perl source.
This is tested on FreeBSD 6.0 & Ubuntu Linux. I'll test later on Windows
& Cygwin.
Randy.
|
|
From: Randy W. S. <ml...@th...> - 2006-03-14 00:44:22
|
Randy W. Sims wrote:
> Randy W. Sims wrote:
>
>> Unfortunately, I don't have a broken system to test on so I'm mostly
>> guessing. I do have an old 633 Mhz Pentium PC laying around somewhere
>> that I can install one of the BSD variant on tonight or tomorrow.
>
> I've been taking my time getting my BSD test system up because I was
> assuming from previous reports that the BSD issue was mostly fixed. I
> finally got it up and configured enough to do some testing, and it looks
> like there are still failures because of the same issue, mostly.
>
> The attached patch is my rough working code to get it fixed.
>
> Module::Build::Base::_perl_is_same needs to set @INC in order to find
> Config.pm when $ENV{PERL_CORE}. Is there a better alternative?
>
> ExtUtils::CBuilder::Base::perl_src needs to check in the current
> directory before moving up. Well, maybe. This really is just a result of
> the way I rewrote Module::Build::Base::find_perl_interpreter to collect
> a list of /all/ candidates before testing for the correct one. If $perl
> and $abs_perl where tested and successful, we could return before the
> call to perl_src(). It's not really a problem except for the spurious
> warning about not find the perl source.
>
> This is tested on FreeBSD 6.0 & Ubuntu Linux. I'll test later on Windows
> & Cygwin.
Ok. With this patch I get no errors, warnings, or any noise on the above
mentioned four platforms.
Any comments on the implementation? The only iffy part from my point of
view is the _perl_is_same method. Is it the best way to handle this?
One other minor change I'd like to make that'd not in the patch is to
change ExtUtils::CBuilder::perl_src to not emit a warning, leaving it up
to the caller to emit a warning if needed.
Other that that, I think the basics are all correct for most platforms.
Randy.
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-07 20:41:48
|
On Tue, Mar 07, 2006 at 12:24:22PM -0800, Yitzchak Scott-Thoennes wrote:
> On Tue, Mar 07, 2006 at 03:10:55PM -0500, Randy W. Sims wrote:
> > Yitzchak Scott-Thoennes wrote:
> > >On Tue, Mar 07, 2006 at 01:32:52PM -0600, Ken Williams wrote:
> > >
> > >>On Mar 7, 2006, at 11:57 AM, Andy Dougherty wrote:
> > >>
> > >>
> > >>>On Tue, 7 Mar 2006, Yitzchak Scott-Thoennes wrote:
> > >>>
> > >>>
> > >>>>Can you try:
> > >>>>
> > >>>>--- lib/Module/Build/Base.pm.orig 2006-03-06 07:43:57.093750000 -0800
> > >>>>+++ lib/Module/Build/Base.pm 2006-03-07 09:00:28.884844800 -0800
> > >>>>@@ -334,7 +334,8 @@
> > >>>> $thisperl .= $exe unless $thisperl =~ m/$exe$/i;
> > >>>> }
> > >>>>
> > >>>>- foreach my $perl ( $c->{perlpath},
> > >>>>+ foreach my $perl ( File::Spec->rel2abs($^X),
> > >>>>+ $c->{perlpath},
> > >>>> map File::Spec->catfile($_, $thisperl),
> > >>>> File::Spec->path()
> > >>>> ) {
> > >>>> return $perl if -f $perl and $proto->_perl_is_same($perl);
> > >>>
> > >>>I'm afraid that didn't help either, since the t/_tmp/Simple/ directory
> > >>>doesn't have a perl executable.
> > >>
> > >>Hmm - so in your case is $^X just 'perl'? If that's the only pointer
> > >>to the currently running perl, we might have to do a PATH search for
> > >>it. Maybe only when it doesn't contain slashes or something.
> > >
> > >
> > >The above code does do a PATH search, but this perl isn't installed.
> > >We might have to do a search up cwd like
> > >ExtUtils::CBuilder::Base::perl_src().
> >
> > I suspect this needs a way to apply the fixup only when running the test
> > && $ENV{PERL_CORE}. The test files are being executed by perl's Makefile
> > or TEST, not being loaded and run from M::B, right? So, when each test
> > file is run it needs (or MBTest.pm needs) to figure out where the perl
> > is that loaded it and apply a fixup. We'll also need to put a hook in
> > M::B to allow the fixup.
> >
> > Randy.
>
> I think just putting code conditional on $ENV{PERL_CORE} in
> find_perl_interpreter is good enough; no need to modify the tests.
>
> It may take us closer to Rafael's request for support for building
> modules with an uninstalled perl, ala makemaker.
With this, I still get a couple of test failures; will look into why later.
--- /home/sthoenna/modbuild/Module-Build-0.27_08/lib/Module/Build/Base.pm 2006-03-03 19:27:57.000000000 -0800
+++ Base.pm 2006-03-07 12:26:09.025250000 -0800
@@ -333,8 +333,15 @@
} elsif (defined $exe) {
$thisperl .= $exe unless $thisperl =~ m/$exe$/i;
}
-
- foreach my $perl ( $c->{perlpath},
+
+ my $uninstperl;
+ if ($ENV{PERL_CORE}) {
+ require ExtUtils::CBuilder;
+ $uninstperl = File::Spec->catfile(ExtUtils::CBuilder::->perl_src, $thisperl);
+ }
+
+ 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);
|
|
From: Randy W. S. <ml...@th...> - 2006-03-07 21:03:19
|
Yitzchak Scott-Thoennes wrote:
> On Tue, Mar 07, 2006 at 12:24:22PM -0800, Yitzchak Scott-Thoennes wrote:
>
>>I think just putting code conditional on $ENV{PERL_CORE} in
>>find_perl_interpreter is good enough; no need to modify the tests.
>>
>>It may take us closer to Rafael's request for support for building
>>modules with an uninstalled perl, ala makemaker.
>
>
> With this, I still get a couple of test failures; will look into why later.
>
> --- /home/sthoenna/modbuild/Module-Build-0.27_08/lib/Module/Build/Base.pm 2006-03-03 19:27:57.000000000 -0800
> +++ Base.pm 2006-03-07 12:26:09.025250000 -0800
> @@ -333,8 +333,15 @@
Thanks, I've applied this in our repository.
Randy.
|
|
From: Ken W. <ke...@ma...> - 2006-03-07 23:36:42
|
On Mar 7, 2006, at 2:24 PM, Yitzchak Scott-Thoennes wrote:
>
> I think just putting code conditional on $ENV{PERL_CORE} in
> find_perl_interpreter is good enough; no need to modify the tests.
If possible, I'd like to avoid that. The fewer conditionals we have
on PERL_CORE the better - they make me nervous because I never really
understand them and I never know if I'm breaking something on blead.
Also, if we can get this bit working without special-casing, it would
probably solve the issue for other people too.
-Ken
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-08 00:54:37
|
On Tue, Mar 07, 2006 at 05:36:30PM -0600, Ken Williams wrote:
>
> On Mar 7, 2006, at 2:24 PM, Yitzchak Scott-Thoennes wrote:
>
> >
> >I think just putting code conditional on $ENV{PERL_CORE} in
> >find_perl_interpreter is good enough; no need to modify the tests.
>
> If possible, I'd like to avoid that. The fewer conditionals we have
> on PERL_CORE the better - they make me nervous because I never really
> understand them and I never know if I'm breaking something on blead.
Maybe I'll try to go through and add some comments at some point.
> Also, if we can get this bit working without special-casing, it would
> probably solve the issue for other people too.
Let me mention how a few minutes browsing of the code makes me think
makemaker does things. First, PERL_CORE and PERL_SRC are properties
that can be provided as parameters to Makefile.PL. PERL_CORE defaults
to $ENV{PERL_CORE} or to 0 if that isn't set. PERL_SRC is the
toplevel directory of the perl sources and is required if PERL_CORE is
set; if it isn't set manually, it will be searched for in .., ../..,
etc. (5 levels max).
I'm not sure how this translates into how Module::Build could work,
especially since some of the things makemaker does differently based
on PERL_CORE have been split off MB into CBuilder. But for now, I
think checking $ENV{PERL_CORE} in Base.pm is more of a step forward
than backward.
|
|
From: Nick Ing-S. <ni...@in...> - 2006-03-09 18:25:22
|
Andy Dougherty <dou...@la...> writes: >On Tue, 7 Mar 2006, Yitzchak Scott-Thoennes wrote: > >You can add Solaris to that list. It's also getting $^X=3D./perl,=20 >and then failing to find it in .../t/_tmp/Simple/perl .=20=20 I thought Alan had given us the magic to get absoulte path? Have we just not incorporated it yet? |
|
From: Rafael Garcia-S. <rga...@ma...> - 2006-03-07 17:30:35
|
Steve Peters wrote: > > Well, here's the rub. It looks like, while it runs, Module::Build > changes directories. When I ran, it tries to look for ./perl in > /home/steve/smoke/perl-current/t/_tmp/Simple, which it won't be able to. > So, Module::Build is completely dependent on what is an absolute path $^X, > $Config, or the environment to figure out what Perl is running it. So, > operating system where $^X returns a relative path (apparently BSDs and Mac > OS X) will all fail the the Module::Build tests. Whether Build.PL > scripts work with a Perl not in the $PATH and run using a relative path > on these OS's is left as an exercise for the reader. I think that's one of the major causes of pain when integrating new modules to the core. I'd like to point out, additionnally, that EU::MM has the ability to run a module from a non-installed perl (it warns the user when it does so, but that works, at least on Linux.) I think this feature is cool, since I use it quite often, and I'd like to have the same ability in M::B. |
|
From: Ken W. <ke...@ma...> - 2006-03-07 19:29:56
|
On Mar 7, 2006, at 9:24 AM, Yitzchak Scott-Thoennes wrote: > > > On darwin, is $^X just the filename, or is it a relative path? It's various values in different contexts. ISTR that on Panther or Jaguar or something, if you used a shebang script with an absolute path in the shebang line, you'd only get a relative path (typically 'perl') in $^X, which isn't helpful. I think that's classic BSD-ish behavior. In Tiger it seems like they may have fixed it. -Ken |
Thanks for helping keep SourceForge clean.
X