Learning Perl Objects, References amp;amp; Modules [Electronic resources] نسخه متنی

13.6 Alternate Installation Locations (PREFIX=...)

Speaking of installation locations,
the Makefile built by the default invocation of
Makefile.PL presumes that the module will be
installed in the system-wide Perl directory that all Perl programs
can access directly with the built-in @INC path.

However, if you are testing a module, you certainly
don't want to install it into the system
directories, possibly corrupting a previous version of your module
and breaking production programs.

Also, if you're not the system administrator,
it's unlikely that you can change those central Perl
directories because that would be a great way to insert a trojan
horse for privileged users to stumble across.[11]

[11] Even if
you weren't the system administrator,
you'd soon have all the powers of the system
administrator.

Luckily, the
Makefile contains provisions for considering an
alternate installation location for scripts, manpages, and libraries.
The easiest way to specify an alternate location is with a
PREFIX value as a parameter on the command line:

$ perl Makefile.PL PREFIX=~/Testing
Checking if your kit is complete...
Looks good
Writing Makefile for Island::Plotting::Maps

Although the messages don't indicate anything
different, the Makefile will now install scripts
to $PREFIX/bin, manpages below
$PREFIX/man, and libraries below
$PREFIX/lib/site_perl. In this case,
you're selected a subdirectory of your home
directory called Testing as the value of
$PREFIX.

If you were a project librarian, managing code for a team of
developers, you might instead say something like:

$ perl Makefile.PL PREFIX=/path/to/shared/area

which then builds the files into a shared area. Of course,
you'd need write privileges to such a directory, and
the rest of the team would have to add the bin
subdirectory to their PATH, the
man subdirectory to their
MANPATH, and the lib/site_perl
directory to their @INC path, as
you'll see shortly.