Front page | perl.perl5.porters |
Postings from October 2009
2009/10/4 Steve Hay <steve.m.hay@googlemail.com>:
> 2009/10/4 Steve Hay <steve.m.hay@googlemail.com>:
>>>> The Makefile.PL contains this snippet in its WriteMakefile() call:
>>>>
>>>> (
>>>> $] >= 5.009 && ! $ENV{PERL_CORE}
>>>> ? (INST_LIB => 'blib/arch')
>>>> : ()
>>>> ),
>>>>
>>>> Given that files are copied from INST_LIB to INSTALLPRIVLIB when
>>>> INSTALLDIRS is set to 'perl' (as it is here), it seems wrong to
>>>> manipulate INST_LIB in this way. It feels more like it is the target
>>>> (INSTALLPRIVLIB) that needs manipulating, not the source (INST_LIB),
>>>> but we'd need to set that to the value of INSTALLARCHLIB (the target
>>>> of INST_ARCH) and I'm not sure how to achieve that.
>>>
>>> The intention of the INST_LIB manipulation was to solve an issue where folk
>>> were running with older versions of the compression modules and they tried
>>> to upgrade to a newer version. A couple of the compression modules
>>> (Compress::Zlib being the key one) that used to be XS based are not anymore.
>>> This was causing upgrade issues with the older versions of the modules were
>>> being found in @INC before the newly installed versions.
>>
>> Yes, I thought that was it.
>>
>>
>>>
>>> Now that the new non-XS versions of the compression modules are available in
>>> an official Perl release (5.101.1) I think it should be safe to change the
>>> logic in Makefile.PL so that the INST_LIB manipulation isn't done for a Perl
>>>>= 5.10.1
>>>
>>> I'll admit that this part of the installation process has always confused
>>> the hell out of me, so if I'm suggesting something stupid please tell me.
>>>
>>
>> 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! So without any INST_LIB
>> manipulation (or something like it) you're back to the original
>> problem of reinstall/upgrades from CPAN putting their new files into
>> lib and being masked by the original core files in the archlib.
>>
>> (Actually only the *nix change above made it into 5.10.1. I was too
>> slow off the mark looking at this, and the Win32 change isn't in a
>> 5.10.x yet.)
>>
>
> Searching through other Makefile.PLs for inspiration, I found an
> interesting bit in Safe's Makefile.PL:
>
> INSTALLDIRS => 'perl',
> ($core || $] >= 5.011) ? () : (INST_LIB => '$(INST_ARCHLIB)'),
>
> This is a slightly nicer version of what's in IO-Compress's
> Makefile.PL, in that $(INST_LIB) and $(INST_ARCHLIB) will now be the
> same, instead of differing in a forward slash vs. backslash. But it's
> still wrong in that it changes the keys of the %from_to hash in the
> ExtUtils::Install::install() call, rather than the values. Using the
> above snippet in IO-Compress gives me:
>
> ... write ... blib\arch c:\perl\lib blib\arch
> c:\perl\lib\MSWin32-x86-multi-thread ...
>
> which says "install files from blib\arch into c:\perl\lib" and
> "install files from blib\arch into
> c:\perl\lib\MSWin32-x86-multi-thread"! That's nonsense. It might only
> do the first instruction, or only do the last, or do both, depending
> on how EU-I is written.
Actually by the time EUI sees this it has already been decided by
MakeMaker/Perl via this:
{@ARGV}
which means the last will be used.
> It's the values of %from_to that we want to change so that we get:
>
> ... write ... blib\lib c:\perl\lib\MSWin32-x86-multi-thread
> blib\arch c:\perl\lib\MSWin32-x86-multi-thread ...
>
> The destinations of INST_LIB and INST_ARCHLIB when INSTALLDIRS is
> 'perl' are INSTALLPRIVLIB and INSTALLARCHLIB respectively, so setting
>
> INSTALLPRIVLIB => '$(INSTALLARCHLIB)'
>
> in IO-Compress's Makefile.PL should do the trick, and indeed the
> attached patch works for me.
>
> Please can someone on *nix check that it works there too? Then we can
> hopefully get a new IO-Compress release out and update blead with it,
> and this horrible thread will be over ;-)
>
> [Except that now I'm wondering about that Makefile.PL trick in Safe
> too. Should it likewise be manipulating the destinations of installed
> files rather than the sources?...]
Havent poked in this, sorry. Will try to later.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next