Front page | perl.perl5.porters |
Postings from October 2009
From: Steve Hay [mailto:steve.m.hay@googlemail.com]
> 2009/10/4 Paul Marquess <Paul.Marquess@ntlworld.com>:
> >> From: Steve Hay [mailto:steve.m.hay@googlemail.com]
> > ...
> >>
> >> I think what you're suggesting wouldn't work precisely because of
> the
> >> core changes:
> >>
> >> http://perl5.git.perl.org/perl.git/commit/4cc80fc (for *nix)
> >> http://perl5.git.perl.org/perl.git/commit/f4a6a71 (for Win32)
> >>
> >> Those change ensure that the new non-XS versions of these modules
> >> available in 5.10.1 get installed into the architecture-dependent
> lib
> >> folder just like the old XS versions!
> >
> > But why does it need to be installed in an architecture-dependent
> folder at
> > all? IO-Compress doesn't (or shouldn't) contain anything
> > architecture-dependent -- all the that logic lives in the Compress-
> Raw-*
> > modules.
>
> It's because of your previous explanation about Compress-Zlib having
> previously been an XS module. We need to continue pretending that it
> still is to avoid upgrade trouble, given that archlib is in @INC
> before lib.
For legacy versions of perl, I agree, I'm stuck with messing with INST_LIB.
For future releases of Perl do we not have the opportunity to make the
problem go away by getting core to assume it not architecture-dependent and
have the latest CPAN version out in the wild know what it should do for Perl
versions >= 5.10.2?
So the logic in Makefile.PL becomes something like this (completely
untested)
(
$] >= 5.009 && $] <= 5.010001 && ! $ENV{PERL_CORE}
? (INSTALLPRIVLIB => '$(INSTALLARCHLIB)')
: ()
)
Paul
Thread Previous
|
Thread Next