Using SGI Perl extension modules
This release of Perl includes a mechanism to ship SGI modules such
that they are available to multiple SGI products, are available for
the customers to use, and let the customer install newer versions
without impacting the operation of SGI products that depend on them.
The mechanism is to create a "sgi_perl" directory that is in the
compiled @INC path, but is after the standard "site_perl" directory
in search order. This allows the customer to use the extension
modules that SGI ships, and if they install their own version, it is
used in place of the SGI one, without the customer doing anything
different than normal.
For details on creating and installing an SGI-extension module, see
the file README.modules in this directory.
The @INC include path compiled into the system Perl is:
/usr/share/lib/perl5/irix-n32/5.003
/usr/share/lib/perl5
/usr/share/lib/perl5/site_perl/irix-n32
/usr/share/lib/perl5/site_perl
/usr/share/lib/perl5/sgi_perl
.
If SGI products based upon Perl do not care about the specific
version of the extension module, they need do nothing special. The
script, when run will get either the version of the module that we
ship, or the newer version that the customer installs. Because the
modules are supported by people who don't even know that we are
shipping it, it is possible that an update may break the SGI shipped
Perl script. If this is a possible problem, there is an easy
work-around: Add the following line before you 'use My::Module;' in
your script:
use lib "/usr/share/lib/perl5/sgi_perl";
which adds that directory to the front of the @INC include path, and
you will always get the SGI-provided module.
The same mechanism works if the products wants to create it's own
private module directory.
