views:

1112

answers:

7

At work I'm using Perl 5.8.0 on Windows.

When I first put Perl on, I went to CPAN, downloaded all the sources, made a few changes (in the .MAK file? to support threads, or things like that), and did nmake / nmake test / nmake install. Then, bit by bit, I've downloaded individual modules from CPAN and done the nmake dance.

So, I'd like to upgrade to a more recent version, but the new one must not break any existing scripts. Notably, a bunch of "use" modules that I've installed must be installed in the new version.

What's the most reliable (and easiest) way to update my current version, ensuring that everything I've done with the nmake dance with will still be there after updating?

+1  A: 
Kev
Given the large number of modifications, the prepackages probably won't work. I've also installed into version named folders and linked from a generic R:\PERL folder to help switching.
piCookie
The changes to the 5.8 makefile are unimportant. I'm more asking how to find which packages above the base install I've obtained. I have a lot of scripts that say "use xxx" where xxx was downloaded and built in. They all need to continue working.
piCookie
This may be a bit lame, but you could use TextPad's "Find in Files" or equivalent to search all your scripts for "^use ".
Kev
+6  A: 

I would seriously consider looking at using Strawberry Perl. http://strawberryperl.com

Andy Lester
Strawberry perl doesn't appear to give me any option about where it's installing. That's a deal breaker in my case.
piCookie
+3  A: 

You can install a second version of Perl in a different location. You'll have to re-install any non-core modules into the new version. In general, different versions of Perl are not binary compatible, which could be an issue if you have any program-specific libraries that utilize XS components. Pure Perl modules shouldn't be affected.

Michael Carman
+3  A: 

If you stay within the 5.8 track, all installed modules that contain XS (binary) extensions will continue to work, as binary compatibility is guarenteed within the same 5.8 series. If you moved to 5.10 then you would have to recompile any modules that contain XS components.

All you need to do is ensure that the new build lists the previous include directories in its @INC array (which is used to look for modules).

By the sounds of it, I think you're on Windows, in which case the current @INC paths can be viewed with

perl -le "print for @INC"

Make sure you target your new Perl version in another directory. It will happily coexist with the previous version, and this will allow you to choose which Perl installation gets used; it's just a question of getting your PATH order sorted out. As soon as a perl interpreter is started up, it knows where to look for the rest of its modules.

Strawberry Perl is probably the nicest distribution on Windows these days for rolling your own.

dland
Does Strawberry allow me to add modules that I've rolled into the 5.8 chain? I'm most happy to move to the latest version, so maintaining 5.8 isn't interesting.
piCookie
+1  A: 

See related article: Which version of perl should I use on Windows

szabgab
+9  A: 
brian d foy
+1  A: 

I think the answer to this involves virtualisation of some kind:

  1. Set up an exact copy of your current live machine. Upgrade Perl, using the same directory locations and structures as you're using at the moment.
  2. Go through your scripts testing them on the new image.
  3. Once you're happy, flip the switch.

The thinking behind this is that there's probably all sorts of subtle dependencies and assumptions you haven't thought of. While unlikely, the latest version of a particular module (possibly even a core module, although that's even more unlikely) might have a subtle difference compared to the one you were using. Unless you've exhaustively gone through your entire codebase, there's quite possibly a particular module that's required only under certain circumstances.

You can try and spot this by building a list of all your scripts - a list that you should have anyway, by dint of all your code being under version control (you are using version control, e.g. Subversion, yes?) - and iterating through it, running perl -c on each script. e.g. this script. That sort of automated test is invaluable: you can set it running, go away for a coffee or whatever, and come back to check whether everything worked. The first few times you'll probably find an obscure module that you'd forgotten about, which is fine: the whole point of automating this is so that you don't have to do the drudge-work of checking every single script.

Sam Kington
Great tip about the perl -c. That will make it very much easier to get a basic sanity check.
piCookie