Usually pure-Perl module files ending in .pm or .pod.
Architecture-dependent module files, usually produced by compiling XS, Inline, or similar code.
Programs written in pure Perl. In order to improve reuse, you may want to make these as small as possible - put the code into modules whenever possible.
Architecture-dependent executable programs, i.e. compiled C code or something. Pretty rare to see this in a perl distribution, but it happens.
Documentation for the stuff in script and bin. Usually generated from the POD in those files. Under Unix, these are manual pages belonging to the man1 category. Unless explicitly set, this is only available on platforms supporting manpages.
Documentation for the stuff in lib and arch. This is usually generated from the POD in .pm and .pod files. Under Unix, these are manual pages belonging to the man3 category. Unless explicitly set, this is only available on platforms supporting manpages.
This is the same as bindoc above, but applies to HTML documents. Unless explicitly set, this is only available when perl was configured to do so.
This is the same as libdoc above, but applies to HTML documents. Unless explicitly set, this is only available when perl was configured to do so.
The default destinations for these installable things come from entries in your systems configuration. You can select from three different sets of default locations by setting the installdirs parameter as follows:
installdirs set to: core site vendor uses the following defaults from ExtUtils::Config: lib => installprivlib installsitelib installvendorlib arch => installarchlib installsitearch installvendorarch script => installscript installsitescript installvendorscript bin => installbin installsitebin installvendorbin bindoc => installman1dir installsiteman1dir installvendorman1dir libdoc => installman3dir installsiteman3dir installvendorman3dir binhtml => installhtml1dir installsitehtml1dir installvendorhtml1dir [*] libhtml => installhtml3dir installsitehtml3dir installvendorhtml3dir [*] * Under some OS (eg. MSWin32) the destination for HTML documents is determined by the C<Config.pm> entry C<installhtmldir>.
The default value of installdirs is site.
You can also set the whole bunch of installation paths by supplying the install_base parameter to point to a directory on your system. For instance, if you set install_base to /home/ken on a Linux system, youll install as follows:
This sets a prefix, identical to ExtUtils::MakeMakers PREFIX option. This does something similar to install_base in a much more complicated way.
config()The ExtUtils::Config object used for this object.
The verbosity of ExtUtils::InstallPaths. It defaults to 0
Together with module_name this controls whether a packlist will be added; it defaults to 1.
The name of the current module.
The name of the main module of the package. This is required for packlist creation, but in the future it may be replaced by dist_name. It defaults to dist_name =~ s/-/::/gr if dist_name is set.
If you want to install everything into a temporary directory first (for instance, if you want to create a directory tree that a package manager like rpm or dpkg could create a package from), you can use the destdir parameter. E.g. Setting destdir to "/tmp/foo" will effectively install to /tmp/foo/$sitelib, /tmp/foo/$sitearch, and the like, except that it will use File::Spec to make the pathnames work correctly on whatever platform youre installing on.
Create a new ExtUtils::InstallPaths object. <B>All attributes are valid argumentsB> to the constructor, as well as this:
This must be a hashref with the type as keys and the destination as values.
This must be a hashref with types as keys and a path relative to the install_base as value.
This must be a hashref any of these three keys: core, vendor, site. Each of the values mush be a hashref with types as keys and a path relative to the prefix as value. You probably want to make these three hashrefs identical.
This must be a hashref with the legal installdirs values as keys and the prefix directories as values.
This mush be a hashref with the legal installdirs are keys, and the values being hashrefs with types as keys and locations as values.
install_map()Return a map suitable for use with ExtUtils::Install. <B>In most cases, this is the only method youll needB>.
Returns the destination of a certain type.
install_types()Return a list of all supported install types in the current configuration.
Given a file type, will return true if the file type would normally be installed when neither install-base nor prefix has been set. I.e. it will be true only if the path is set from the configuration object or set explicitly by the user via install_path.
Gets the install path for a certain type.
install_sets($installdirs, CW$type)Get the path for a certain $type with a certain $installdirs.
install_base_relpaths($type, CW$relpath)Get the relative paths for use with install_base for a certain type.
prefix_relative($installdirs, CW$type)Gets the path of a certain $type and $installdirs relative to the prefix.
prefix_relpaths($install_dirs, CW$type)Get the default relative path to use in case the config install paths cannot be prefixified. You do not want to use this to get any relative path, but may require it to set it for custom types.
Get the original prefix for a certain type of $installdirs.
o Ken Williams <email@example.com> o Leon Timmermans <firstname.lastname@example.org>
This software is copyright (c) 2011 by Ken Williams, Leon Timmermans.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
|perl v5.20.3||EXTUTILS::INSTALLPATHS (3)||2015-02-15|