[Melbourne-pm] How to build a local module repository

Sisyphus sisyphus1 at optusnet.com.au
Sun Jun 1 22:27:04 PDT 2008


----- Original Message ----- 
From: "Ian Macdonald" <ickphum at gmail.com>
.
.
>
> We're currently trialling Strawberry Perl as an alternative to ASPerl

You can, of course, use the dmake and mingw32 compiler that ships with 
Strawberry Perl, to build modules on ActivePerl. If Strawberry's c/bin is in 
the path, then (recent versions of) ActivePerl will automatically find dmake 
and mingw32, and use them to build modules. That is, dmake and mingw32 will 
work just as well with ActivePerl as they do with Strawberry Perl.
Going in the opposite direction, the ppm packages that have been built for 
ActivePerl, will work just as well on Strawberry Perl.
(You may already have been fully aware of that ... just thought I'd mention 
it in case you weren't, and could make use of it :-)

>
> PS on a related note; we've also thought about installing CPAN modules on
> new boxes by simply copying the perl/site directory from a working box.
> Assuming that the OS matches down to the patch level, is this a safe
> approach?


Two unlikely (but theoretically possible) gotchas:

1) ActiveState, at some time during their 5.8.x releases (I think it was 
during their 5.8.8 releases), started placing non-core modules that they 
shipped with their distros into perl/lib. Earlier builds had those modules 
placed in perl/site/lib. So there's a window of opportunity that this 
approach could lead to a situation where a particular installation of 
ActiveState perl ends up with certain modules in both perl/lib and 
perl/site/lib. This has the potential to be a little confusing - and even 
troublesome. If all of your WinXP ActivePerls have the same build number, 
then there's nothing to worry about on that score. (If they don't have the 
same build number, just check that the @INC ordering is the same.)

2) If a particular module has some hard coded paths built into it's config, 
and you copy it to a machine where those paths need to be different (eg 
because perl has been installed in a different location), then it's not 
going to work. For example, this is an issue with PDL, but you're probably 
not using PDL. I can't think of any other cases where this could happen - 
but they may exist.

Cheers,
Rob 



More information about the Melbourne-pm mailing list