At $work, we maintain a set of Perl modules at a central location for easy inclusion via PERL5LIB. As there is a re-installation ahead and we need to provide the modules for both 32 and 64 bit architecture, we are开发者_StackOverflow中文版 wondering if it's better to install them into the same directory tree, relying on the $archname subdirectories, or keep the two architectures entirely separate and duplicate each module.
I was not very successful at researching the inner workings of the Perl module lookup process involving $archname, maybe someone can point me in the right direction.
In your experience, what are the pros and cons of the two approaches?
From perldoc lib:
When using use lib LIST;
For each directory in LIST (called
$dir
here) the lib module also checks to see if a directory called$dir/$archname/auto
exists. If so the$dir/$archname
directory is assumed to be a corresponding architecture specific directory and is added to @INC in front of$dir
.
lib.pm
also checks if directories called$dir/$version
and$dir/$version/$archname
exist and adds these directories to @INC.
IMHO, it is more idiomatic - and dare I say, neater - to use the per-architecture subdirectories, like Perl's standard libraries would.
However, it night be more straightforward to manage per-architecture-entire-tree of your own libraries, though not by a large margin once you create a few basic tools/scripts to do so.
Build the modules separately on each system so that you only get the files needed there. Or use a packaging system that distinguishes between architectures. Don't try to provide the files for all architectures to all systems.
精彩评论