suaveant has asked for the wisdom of the Perl Monks concerning the following question:

My company is making the move to Linux and as it is happening piecemeal, parts of my groups code is on Linux and part on Solaris. Now, to save the hassle of getting another department to add modules etc into the system, I have my own Perl modules directory. To distribute and manage this in dev and production I have a CVS module. Now, with the architecture specific subdirectories I though maybe I could use one module, but apparently many architecture specific modules break up their Perl parts into the non-arch dir and the arch specific into the arch-specific dir. Therefore when I go to do an install of an arch-specific Perl module on the second arch, CPAN complains that the module is already installed.

So what is the best way to handle multiple architectures. Forcing installs seems messy since it ignores tests (and may not be recursive for dependencies, not sure). Do I just maintain two entirely separate modules and call it good, or is there a better solution?

                - Ant
                - Some of my best work - (1 2 3)

  • Comment on Module management and multiple architectures

Replies are listed 'Best First'.
Re: Module management and multiple architectures
by Tanktalus (Canon) on Feb 08, 2007 at 21:12 UTC

    I do something similar to this on AIX, Sun, HP, Linux ... I can't exactly cut&paste the code, but I can give you an idea. So treat this not as untested code, but as pseudocode.

    Read more... (3 kB)
    There's lots more to do ... but that may give you an idea.

[reply]
[d/l]
Re: Module management and multiple architectures
by dragonchild (Archbishop) on Feb 09, 2007 at 01:50 UTC
    I'm not really understanding the problem. What's wrong with keeping the modules (and every single dep) in CVS (why not SVN?!) and do a local user-level install to a separate dir whenever you hit prod? That way, you're doing a clean install to a known place. Sounds like that should "Just Work".
    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      Well... I was trying to install them into one directory so that pure perl modules only needed to be installed once for all architectures. So my dir structure would be 
      /perl
/perl/sun4-solaris
/perl/i686-linux

      [download]
      That is probably asking for trouble, though, since if I installed an arch specific that had files in the base dir on only one machine, or upgraded on only one, it would be there but broken on the other.

      Probably will just keep them separate but in CVS, either in different modules or in different dirs under the same module.

      As for SVN, don't get me started. I've been bugging people for a year to let us use SVN and its looking like we might be able to sometime in the near future.

                      - Ant
                      - Some of my best work - (1 2 3)

[reply]
[d/l]
        This sounds like a false economy. CPU cycles are MUCH cheaper than developer cycles. Don't waste your time. Plus, as you correctly recognize, upgrades on one arch could break the other.

        This is assuming that the pure-perl versions of a file will be the same for various installations. You're also assuming the same Perl version with the same Perl compiler switches. Much safer just to install locally on every machine.

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

Back to Seekers of Perl Wisdom