calmsacibis995
44 lines
1.8 KiB
Plaintext
44 lines
1.8 KiB
Plaintext
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.
|