Thread: [Module-build-general] ExtUtils::ParseXS & 5.00503
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Dave R. <au...@ur...> - 2003-03-29 21:36:40
|
Module::Build passes most of its tests with 5.00503 now, but
ExtUtils::ParseXS does not. There are two things in EU::ParseXS that need
fixing. One if the "open my $fh" idiom, which is simple enough to fix.
But it also uses the "(??{$foo})" regex feature, which is not present in
5.00503. I don't think replacing this would be simple, to say the least
;) I think the easiest way to do this would be to use Text::Balanced, but
this introduces another dependency, and would require a fair bit of code
surgery. I could take a shot if you want, Ken.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
|
|
From: Ken W. <ke...@ma...> - 2003-03-30 03:44:28
|
On Saturday, March 29, 2003, at 03:35 PM, Dave Rolsky wrote:
> Module::Build passes most of its tests with 5.00503 now, but
> ExtUtils::ParseXS does not. There are two things in EU::ParseXS that
> need
> fixing. One if the "open my $fh" idiom, which is simple enough to fix.
>
> But it also uses the "(??{$foo})" regex feature, which is not present
> in
> 5.00503. I don't think replacing this would be simple, to say the
> least
> ;) I think the easiest way to do this would be to use Text::Balanced,
> but
> this introduces another dependency, and would require a fair bit of
> code
> surgery. I could take a shot if you want, Ken.
It would be great, of course - but a simpler solution might be to just
fix the warning buzzers so that optional modules don't look like
required modules to the user. M::B should work fine without
EU::ParseXS, using whatever xsubpp is on the machine.
In the future we might want to really depend on EU::ParseXS, but so far
it'll do fine with either.
-Ken
|
|
From: Dave R. <au...@ur...> - 2003-03-30 05:14:39
|
On Sat, 29 Mar 2003, Ken Williams wrote: > It would be great, of course - but a simpler solution might be to just > fix the warning buzzers so that optional modules don't look like > required modules to the user. M::B should work fine without > EU::ParseXS, using whatever xsubpp is on the machine. > > In the future we might want to really depend on EU::ParseXS, but so far > it'll do fine with either. In that case, how about tweaking the EU::ParseXS test to make sure that the module actually loads, and skipping tests if it doesn't. If people are sharing pure Perl modules between multiple Perl installations, they might be put off from installing Module::Build with 5.00503 if there are test failures. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Ken W. <ke...@ma...> - 2003-03-30 05:20:49
|
On Saturday, March 29, 2003, at 11:13 PM, Dave Rolsky wrote: > On Sat, 29 Mar 2003, Ken Williams wrote: > >> It would be great, of course - but a simpler solution might be to just >> fix the warning buzzers so that optional modules don't look like >> required modules to the user. M::B should work fine without >> EU::ParseXS, using whatever xsubpp is on the machine. >> >> In the future we might want to really depend on EU::ParseXS, but so >> far >> it'll do fine with either. > > In that case, how about tweaking the EU::ParseXS test to make sure that > the module actually loads, and skipping tests if it doesn't. If people > are sharing pure Perl modules between multiple Perl installations, they > might be put off from installing Module::Build with 5.00503 if there > are > test failures. > That test should pass (not be skipped) even if EU::ParseXS isn't around. You're seeing it fail? This is t/xs.t in Module::Build, right? -Ken |
|
From: Dave R. <au...@ur...> - 2003-03-30 06:04:20
|
On Sat, 29 Mar 2003, Ken Williams wrote:
> That test should pass (not be skipped) even if EU::ParseXS isn't
> around. You're seeing it fail? This is t/xs.t in Module::Build, right?
I was a little confused. If EU::ParseXS _is_ installed and you try to
load it with Perl 5.00503, it does actually load (I thought it was
dying), but it doesn't work right. So here's a test patch that skips
the tests unconditionally if you're using a Perl before 5.6.0.
Index: xs.t
===================================================================
RCS file: /cvsroot/module-build/Module-Build/t/xs.t,v
retrieving revision 1.5
diff -u -r1.5 xs.t
--- xs.t 24 Feb 2003 18:23:20 -0000 1.5
+++ xs.t 30 Mar 2003 06:02:16 -0000
@@ -3,6 +3,8 @@
use strict;
use Test;
+print("1..0 # Skipped: cannot use ExtUtils::ParseXS with Perl $]\n"), exit(0)
+ if $] < 5.006;
print("1..0 # Skipped: no compiler found\n"), exit(0) unless have_compiler();
plan tests => 7;
|
|
From: Ken W. <ke...@ma...> - 2003-03-30 15:45:06
|
On Sunday, March 30, 2003, at 12:03 AM, Dave Rolsky wrote:
> On Sat, 29 Mar 2003, Ken Williams wrote:
>
>> That test should pass (not be skipped) even if EU::ParseXS isn't
>> around. You're seeing it fail? This is t/xs.t in Module::Build,
>> right?
>
> I was a little confused. If EU::ParseXS _is_ installed and you try to
> load it with Perl 5.00503, it does actually load (I thought it was
> dying), but it doesn't work right. So here's a test patch that skips
> the tests unconditionally if you're using a Perl before 5.6.0.
Since when are we in the practice of skipping a test when we discover
it doesn't work! =) It needs to be fixed, not skipped. If it remains
broken, then M::B is broken on that platform for compiling XS modules.
If ExtUtils::ParseXS doesn't work on 5.005, then you probably shouldn't
have installed it in a location shared with 5.005. But I'm sort of
glad you did, because probably other people will too, and we shouldn't
be loading a module that doesn't work.
How about this patch instead of yours:
-Ken
Index: lib/Module/Build/Base.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
retrieving revision 1.80
diff -u -r1.80 Base.pm
--- lib/Module/Build/Base.pm 30 Mar 2003 06:06:16 -0000 1.80
+++ lib/Module/Build/Base.pm 30 Mar 2003 15:42:16 -0000
@@ -1184,7 +1184,8 @@
print "$file -> $file_base.c\n";
- if (eval {require ExtUtils::ParseXS; 1}) {
+ # ExtUtils::ParseXS requires 5.6, but it's in @INC sometimes anyway.
+ if ($] >= 5.006 and eval {require ExtUtils::ParseXS; 1}) {
ExtUtils::ParseXS::process_file(
filename => $file,
===================================================================
|
|
From: Dave R. <au...@ur...> - 2003-03-30 16:31:22
|
On Sun, 30 Mar 2003, Ken Williams wrote: > Since when are we in the practice of skipping a test when we discover > it doesn't work! =) It needs to be fixed, not skipped. If it remains > broken, then M::B is broken on that platform for compiling XS modules. I think I was just confused about the M::B internals. > If ExtUtils::ParseXS doesn't work on 5.005, then you probably shouldn't > have installed it in a location shared with 5.005. But I'm sort of > glad you did, because probably other people will too, and we shouldn't > be loading a module that doesn't work. Exactly. Someone might install it into a shared location with 5.6.1, and then try it with 5.00503 and kaboom! > How about this patch instead of yours: Looks good to me. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/ |
|
From: Richard C. <ric...@un...> - 2003-03-30 23:50:28
|
On Sun, Mar 30, 2003 at 09:44:59AM -0600, Ken Williams wrote:
> If ExtUtils::ParseXS doesn't work on 5.005, then you probably shouldn't
> have installed it in a location shared with 5.005. But I'm sort of
> glad you did, because probably other people will too, and we shouldn't
> be loading a module that doesn't work.
>
> How about this patch instead of yours:
Forgive me for coming late to the game, but surely the simplest fix
goes a bit like:
package ExtUtils::ParseXS;
+ use 5.006; # /??{}/ won't mean the right thing unless we're this new
And then up the value of the suggestion on EU::PXS in Module::Build's
Build.PL to a version that incorporates that change.
--
Richard Clamp <ric...@un...>
|
|
From: Ken W. <ke...@ma...> - 2003-03-31 00:04:56
|
On Sunday, March 30, 2003, at 05:49 PM, Richard Clamp wrote:
> On Sun, Mar 30, 2003 at 09:44:59AM -0600, Ken Williams wrote:
>> If ExtUtils::ParseXS doesn't work on 5.005, then you probably
>> shouldn't
>> have installed it in a location shared with 5.005. But I'm sort of
>> glad you did, because probably other people will too, and we shouldn't
>> be loading a module that doesn't work.
>>
>> How about this patch instead of yours:
>
> Forgive me for coming late to the game, but surely the simplest fix
> goes a bit like:
>
> package ExtUtils::ParseXS;
> + use 5.006; # /??{}/ won't mean the right thing unless we're this new
>
> And then up the value of the suggestion on EU::PXS in Module::Build's
> Build.PL to a version that incorporates that change.
That's just crazy enough to work!
It's about the same as my previous fix, except that it places the
burden of upgrading in ExtUtils::ParseXS instead of Module::Build,
which is good. Thanks for the suggestion.
-Ken
|
Thanks for helping keep SourceForge clean.
X