views:

39

answers:

2

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 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?

+3  A: 

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.

DVK
+1  A: 

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.

ysth
@ysth - if it's just 2 architectures, what would be the downsides of doing "all files for all architectures on all systems" approach? Assuming there are no uber-huge binaries to make storage a concern...
DVK
And when you get another architecture? Or a newer distribution with a different perl version? It just feels like a kludge.
ysth
@ysth - (1) there aren't enough distinct architectures to make this a maintenance issue, IMHO. As far as versions, I would strongly recommend per-version tree based on ease of use from personal experience.
DVK