http://www.perlmonks.org?node_id=959393


in reply to Perl 64-bit versions

Sorry I do not emphasize on Windows, but I'd like to share my thoughts too.

First off, anything 5.10.1 and up is fine with me. I really want defined-or in my code, but as I was able to patch perl-5.8.x, I had that since 5.8.1. All below 5.8.4 is crap when you want Unicode support.

The way 5.14.x and up deals with charnames and Unicode was a reason for me to upgrade to 5.14.1 and I ran into no serious problems perl-wise. The problems I ran into were module related: e.g. the newest version of DBD::Oracle only works with Oracle-10 and up. My box had oracle 9. Then one has to dive to BackPAN to find the last module that works with a new perl and an old environment. That is what is taking long long long time and is no fun, certainly if the maintainer of the module switched somewhere between the working version on your previous perl and the not-working version on the new perl.

I never enable old perl trees in my new environment. I build perl to ignore old trees, so I can remove them when all tests passed. Not only to keep the disks clean (I have to copy most of it to customers too, and having a sanatized tree makes that a lot easier to do), but also this forces me to test every module I use on the new perl.

That said, with so many modules to install, you should have a look into cpanprefs and make a "Bundle" of what you have now and install the Bundle into the new perl. If you make the right preferences to cpanprefs, a single cpan command can run for up to 50 hours unattended! (been there, done that).


Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re^2: Perl 64-bit versions
by BrowserUk (Patriarch) on Mar 13, 2012 at 16:38 UTC
    That said, with so many modules to install, you should have a look into cpanprefs and make a "Bundle"

    In general, I found that anything cpan* could install automatically, is available as a ppm from AS. And 

    \oldperl\ppm profile save \ppmprofile.5.10.1
path = \newperl\bin;...
\newperl\pp profile restore \ppmprofile.5.10.1

    [download]

    Dealt with most of the 272 ppms in a matter of a few minutes. It took it longer to download the packing list than it did to download and install all the packages that were available.

    The problem child(s) are those that won't install automatically. The ones that need manual tweaks to adapt for *nix-isms or 64-bitisms. I keep the source trees (with my modifications) kicking around and can copy them over, but it still requires going through and building them manually -- including doing the dependencies in the right order. It is just a painful process and one I'd rather keep to a minimum.

    Keeping up with 5.8.x upgrades was pretty easy. With binary compatibility being maintained, I could just throw the latest version in over the top of the previous and mostly everything just still worked. But with the last half dozen versions having broken binary compatibility 3 times "keeping up" seems to be a game for those that like to spend their time building Perl rather than using it.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?
[reply]
[d/l]

      The problems that I have seen with 64bitness have diminished to almost neglectable. The most problems I have seen in the incompatibility area are with longdoubles.


      Enjoy, Have FUN! H.Merijn
[reply]
        FWIW, I've got both 32bit & 64bit AS versions (5.14.2) on my box right now. I use the 32bit when I need Win32::API .

        TJD

[reply]

In Section Seekers of Perl Wisdom