perlquestion
syphilis
Hi,<br><br>
I have an "architectured" perl installation where, in addition to <c>perl/site/lib</c>, I also have:
<c>
perl/site/lib/MSWin32-x64-multi-thread
perl/site/lib/MSWin32-x64-multi-thread-ld
perl/site/lib/MSWin32-x64-multi-thread-quadmath
perl/site/lib/MSWin32-x86-multi-thread
perl/site/lib/MSWin32-x86-multi-thread-64int
perl/site/lib/MSWin32-x86-multi-thread-64int-ld
perl/site/lib/MSWin32-x86-multi-thread-64int-quadmath
perl/site/lib/MSWin32-x86-multi-thread-ld
perl/site/lib/MSWin32-x86-multi-thread-quadmath
</c>
Pure-perl modules will, by default, be installed into <c>perl/site/lib</c>.
<br>Other modules (ie perl extensions) will be installed into the appropriate location listed above, according to the perl architecture for which they have been built.
<br><br>I have a perl extension called (say) Module::B, and it has been built and installed into each of those architecture-specific locations.
<br>There also exists a pure-perl Module::A, which requires Module::B but has not yet been installed anywhere into that perl.
<br><br>Using (say) the <c>MSWin32-x64-multi-thread</c> build of perl, I then install Module::A in the usual way (<c>cpan -i Module::A</c>).
<br>Module::A gets installed into <c>perl/site/lib</c> because it is a pure-perl module.
<br>At that point, Module::A becomes immediately available to all 9 architectures, even though it has not been tested against 8 of them.
<br><br>This is an unsatisfactory state of affairs, IMO.
<br>I envisage that Module::A should really be installed into the relevant architecture-specific location.
<br>How do I tell ExtUtils::MakeMaker to do that ?
<br>Or is there some better way of handling this ?
<br>How do module authors generally deal with this issue ?
<br><br>Cheers,<br>Rob