Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

We run the identical version of Perl with an identical set of CPAN modules on all our many different Unix boxes (multiple versions of: AIX, HP-UX, Solaris, Red Hat Enterprise Linux (RHEL), Digital UNIX, Tru64 UNIX, IRIX, UnixWare, SCO Unix, ...).

I install this perl in the same well-known location on each of our boxes and adjust the PATH so that we use this version of Perl for all our work. We never use, or meddle with, the system /usr/bin/perl. We also ship our Perl distribution with all our products. Using the same (stable) Perl distribution everywhere avoids many annoying portability glitches ("it's easier to port a shell than a shell script").

To achieve this, I put the source tarballs for perl and all the CPAN modules on a shared drive available to all our Unix boxes, then run a script that builds perl from source (Configure, make, make test, make install), followed by building all the CPAN modules from source (perl Makefile.PL, make, make test, make install). The script contains an array of CPAN modules and builds them in the specified order. Because our Perl distribution must run on customer machines, and we don't want to meddle with their /usr/lib or /usr/local/lib, I have to take care to build any CPAN modules that depend on C libraries (e.g. XML-Parser) in such a way that they are wholly contained in our Perl distribution and don't depend on the contents of /usr/lib or /usr/local/lib. Only our build script is currently under version control. It would be easy to put all the tarballs under version control also -- and I probably should -- though I haven't bothered so far, mainly because they are essentially unchanged from the CPAN tarballs.

This scheme has worked reasonably well here because we require stability and repeatability (we typically update our Perl distribution only once every two years or so). One nuisance is when we need to make an emergency fix to a CPAN module. In that rare event, I unpack the CPAN module tarball, make the fix, then repack it into a new tarball with a different name, updating our build script to use the new tarball. Ugly. Since I've only needed to do this once, I haven't investigated a better way to deal with this use case. Ideas welcome. Notice that if you need to make an emergency fix like this, it's in your best interests to send the fix back to the module author as soon as possible, so as to get a proper code review and to avoid the long term burden of maintaining your own custom fork.

Though the above scheme has worked well for me here, it's probably not appropriate in a more volatile Perl environment, and I'm interested to hear how other folks deal with that.

BTW, so as not to meddle with customer /usr/lib or /usr/local/lib (and to avoid the dreaded LD_LIBRARY_PATH, see also Re: Portable Perl?), and to not require root permissions, our install script used to binary-edit our executables, replacing their artificially long build PATH with the customer chosen install directory with our lib sub-directory appended.

Related CPAN Modules

Pinto References

Related Perl Monks Nodes

  • Re: Out-of-the box Perl version - lowest common denominator by me (2021) - notes that non-technical customers lack the skills and desire to build their own perl ... while building our own perl vastly improves and simplifies customer support, e.g. it's easy to set up test environments in our office identical to what the customer is using
  • Howto Bundle Perl (2009) - asks for advice on bundling Solaris perl with a software product that depends on it

References Added Later

Updated: "Related CPAN Modules" and following sections were added long after the original reply was made.


In reply to Re: putting perl and modules in your source code repository by eyepopslikeamosquito
in thread putting perl and modules in your source code repository by perl5ever

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2024-03-29 01:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found