Alien-V8
view release on metacpan or search on metacpan
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
interix Unix
gnu Unix
gnukfreebsd Unix
nto Unix
dos Windows
MSWin32 Windows
os390 EBCDIC
os400 EBCDIC
posix-bc EBCDIC
vmesa EBCDIC
MacOS MacOS
VMS VMS
VOS VOS
riscos RiscOS
amigaos Amiga
mpeix MPEiX
);
# Inserts the given module into the @ISA hierarchy between
# Module::Build and its immediate parent
sub _interpose_module {
my ($self, $mod) = @_;
eval "use $mod";
die $@ if $@;
no strict 'refs';
my $top_class = $mod;
while (@{"${top_class}::ISA"}) {
last if ${"${top_class}::ISA"}[0] eq $ISA[0];
$top_class = ${"${top_class}::ISA"}[0];
}
@{"${top_class}::ISA"} = @ISA;
@ISA = ($mod);
}
if (grep {-e File::Spec->catfile($_, qw(Module Build Platform), $^O) . '.pm'} @INC) {
__PACKAGE__->_interpose_module("Module::Build::Platform::$^O");
} elsif (exists $OSTYPES{$^O}) {
__PACKAGE__->_interpose_module("Module::Build::Platform::$OSTYPES{$^O}");
} else {
warn "Unknown OS type '$^O' - using default settings\n";
}
sub os_type { $OSTYPES{$^O} }
sub is_vmsish { return ((os_type() || '') eq 'VMS') }
sub is_windowsish { return ((os_type() || '') eq 'Windows') }
sub is_unixish { return ((os_type() || '') eq 'Unix') }
1;
__END__
=for :stopwords
bindoc binhtml destdir distcheck distclean distdir distmeta distsign disttest
fakeinstall html installdirs installsitebin installsitescript installvendorbin
installvendorscript libdoc libhtml pardist ppd ppmdist realclean skipcheck
testall testcover testdb testpod testpodcoverage versioninstall
=head1 NAME
Module::Build - Build and install Perl modules
=head1 SYNOPSIS
Standard process for building & installing modules:
perl Build.PL
./Build
./Build test
./Build install
Or, if you're on a platform (like DOS or Windows) that doesn't require
the "./" notation, you can do this:
perl Build.PL
Build
Build test
Build install
=head1 DESCRIPTION
C<Module::Build> is a system for building, testing, and installing
Perl modules. It is meant to be an alternative to
C<ExtUtils::MakeMaker>. Developers may alter the behavior of the
module through subclassing in a much more straightforward way than
with C<MakeMaker>. It also does not require a C<make> on your system
- most of the C<Module::Build> code is pure-perl and written in a very
cross-platform way. In fact, you don't even need a shell, so even
platforms like MacOS (traditional) can use it fairly easily. Its only
prerequisites are modules that are included with perl 5.6.0, and it
works fine on perl 5.005 if you can install a few additional modules.
See L<"MOTIVATIONS"> for more comparisons between C<ExtUtils::MakeMaker>
and C<Module::Build>.
To install C<Module::Build>, and any other module that uses
C<Module::Build> for its installation process, do the following:
perl Build.PL # 'Build.PL' script creates the 'Build' script
./Build # Need ./ to ensure we're using this "Build" script
./Build test # and not another one that happens to be in the PATH
./Build install
This illustrates initial configuration and the running of three
'actions'. In this case the actions run are 'build' (the default
action), 'test', and 'install'. Other actions defined so far include:
build manpages
clean pardist
code patch_blead
config_data ppd
diff ppmdist
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
F<MANIFEST> file, and vice versa. (See L<manifest> for details.)
=item distclean
[version 0.05]
Performs the 'realclean' action and then the 'distcheck' action.
=item distdir
[version 0.05]
Creates a "distribution directory" named C<$dist_name-$dist_version>
(if that directory already exists, it will be removed first), then
copies all the files listed in the F<MANIFEST> file to that directory.
This directory is what the distribution tarball is created from.
=item distmeta
[version 0.21]
Creates the F<META.yml> file that describes the distribution.
F<META.yml> is a file containing various bits of I<metadata> about the
distribution. The metadata includes the distribution name, version,
abstract, prerequisites, license, and various other data about the
distribution. This file is created as F<META.yml> in YAML format.
It is recommended that the C<YAML::Tiny> module be installed to create it.
If the C<YAML::Tiny> module is not installed, an internal module supplied
with Module::Build will be used to write the META.yml file, and this
will most likely be fine.
F<META.yml> file must also be listed in F<MANIFEST> - if it's not, a
warning will be issued.
The current version of the F<META.yml> specification can be found at
L<http://module-build.sourceforge.net/META-spec-current.html>
=item distsign
[version 0.16]
Uses C<Module::Signature> to create a SIGNATURE file for your
distribution, and adds the SIGNATURE file to the distribution's
MANIFEST.
=item disttest
[version 0.05]
Performs the 'distdir' action, then switches into that directory and
runs a C<perl Build.PL>, followed by the 'build' and 'test' actions in
that directory.
=item docs
[version 0.20]
This will generate documentation (e.g. Unix man pages and HTML
documents) for any installable items under B<blib/> that
contain POD. If there are no C<bindoc> or C<libdoc> installation
targets defined (as will be the case on systems that don't support
Unix manpages) no action is taken for manpages. If there are no
C<binhtml> or C<libhtml> installation targets defined no action is
taken for HTML documents.
=item fakeinstall
[version 0.02]
This is just like the C<install> action, but it won't actually do
anything, it will just report what it I<would> have done if you had
actually run the C<install> action.
=item help
[version 0.03]
This action will simply print out a message that is meant to help you
use the build process. It will show you a list of available build
actions too.
With an optional argument specifying an action name (e.g. C<Build help
test>), the 'help' action will show you any POD documentation it can
find for that action.
=item html
[version 0.26]
This will generate HTML documentation for any binary or library files
under B<blib/> that contain POD. The HTML documentation will only be
installed if the install paths can be determined from values in
C<Config.pm>. You can also supply or override install paths on the
command line by specifying C<install_path> values for the C<binhtml>
and/or C<libhtml> installation targets.
=item install
[version 0.01]
This action will use C<ExtUtils::Install> to install the files from
C<blib/> into the system. See L<"INSTALL PATHS">
for details about how Module::Build determines where to install
things, and how to influence this process.
If you want the installation process to look around in C<@INC> for
other versions of the stuff you're installing and try to delete it,
you can use the C<uninst> parameter, which tells C<ExtUtils::Install> to
do so:
./Build install uninst=1
This can be a good idea, as it helps prevent multiple versions of a
module from being present on your system, which can be a confusing
situation indeed.
=item installdeps
[version 0.36]
This action will use the C<cpan_client> parameter as a command to install
missing prerequisites. You will be prompted whether to install
optional dependencies.
The C<cpan_client> option defaults to 'cpan' but can be set as an option or in
F<.modulebuildrc>. It must be a shell command that takes a list of modules to
install as arguments (e.g. 'cpanp -i' for CPANPLUS). If the program part is a
relative path (e.g. 'cpan' or 'cpanp'), it will be located relative to the perl
program that executed Build.PL.
/opt/perl/5.8.9/bin/perl Build.PL
./Build installdeps --cpan_client 'cpanp -i'
# installs to 5.8.9
=item manifest
[version 0.05]
This is an action intended for use by module authors, not people
installing modules. It will bring the F<MANIFEST> up to date with the
files currently present in the distribution. You may use a
F<MANIFEST.SKIP> file to exclude certain files or directories from
inclusion in the F<MANIFEST>. F<MANIFEST.SKIP> should contain a bunch
of regular expressions, one per line. If a file in the distribution
directory matches any of the regular expressions, it won't be included
in the F<MANIFEST>.
The following is a reasonable F<MANIFEST.SKIP> starting point, you can
add your own stuff to it:
^_build
^Build$
^blib
~$
\.bak$
^MANIFEST\.SKIP$
CVS
See the L<distcheck> and L<skipcheck> actions if you want to find out
what the C<manifest> action would do, without actually doing anything.
=item manpages
[version 0.28]
This will generate man pages for any binary or library files under
B<blib/> that contain POD. The man pages will only be installed if the
install paths can be determined from values in C<Config.pm>. You can
also supply or override install paths by specifying there values on
the command line with the C<bindoc> and C<libdoc> installation
targets.
=item pardist
[version 0.2806]
Generates a PAR binary distribution for use with L<PAR> or L<PAR::Dist>.
It requires that the PAR::Dist module (version 0.17 and up) is
installed on your system.
=item ppd
[version 0.20]
Build a PPD file for your distribution.
This action takes an optional argument C<codebase> which is used in
the generated PPD file to specify the (usually relative) URL of the
distribution. By default, this value is the distribution name without
any path information.
Example:
./Build ppd --codebase "MSWin32-x86-multi-thread/Module-Build-0.21.tar.gz"
=item ppmdist
[version 0.23]
Generates a PPM binary distribution and a PPD description file. This
action also invokes the C<ppd> action, so it can accept the same
C<codebase> argument described under that action.
This uses the same mechanism as the C<dist> action to tar & zip its
output, so you can supply C<tar> and/or C<gzip> parameters to affect
the result.
=item prereq_data
[version 0.32]
This action prints out a Perl data structure of all prerequisites and the versions
required. The output can be loaded again using C<eval()>. This can be useful for
external tools that wish to query a Build script for prerequisites.
=item prereq_report
[version 0.28]
This action prints out a list of all prerequisites, the versions required, and
the versions actually installed. This can be useful for reviewing the
configuration of your system prior to a build, or when compiling data to send
for a bug report.
=item pure_install
[version 0.28]
This action is identical to the C<install> action. In the future,
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
=head2 Environment variables
=over
=item MODULEBUILDRC
[version 0.28]
Specifies an alternate location for a default options file as described above.
=item PERL_MB_OPT
[version 0.36]
Command line options that are applied to Build.PL or any Build action. The
string is split as the shell would (e.g. whitespace) and the result is
prepended to any actual command-line arguments.
=back
=head1 INSTALL PATHS
[version 0.19]
When you invoke Module::Build's C<build> action, it needs to figure
out where to install things. The nutshell version of how this works
is that default installation locations are determined from
F<Config.pm>, and they may be overridden by using the C<install_path>
parameter. An C<install_base> parameter lets you specify an
alternative installation root like F</home/foo>, and a C<destdir> lets
you specify a temporary installation directory like F</tmp/install> in
case you want to create bundled-up installable packages.
Natively, Module::Build provides default installation locations for
the following types of installable items:
=over 4
=item lib
Usually pure-Perl module files ending in F<.pm>.
=item arch
"Architecture-dependent" module files, usually produced by compiling
XS, L<Inline>, or similar code.
=item script
Programs written in pure Perl. In order to improve reuse, try to make
these as small as possible - put the code into modules whenever
possible.
=item bin
"Architecture-dependent" executable programs, i.e. compiled C code or
something. Pretty rare to see this in a perl distribution, but it
happens.
=item bindoc
Documentation for the stuff in C<script> and C<bin>. Usually
generated from the POD in those files. Under Unix, these are manual
pages belonging to the 'man1' category.
=item libdoc
Documentation for the stuff in C<lib> and C<arch>. This is usually
generated from the POD in F<.pm> files. Under Unix, these are manual
pages belonging to the 'man3' category.
=item binhtml
This is the same as C<bindoc> above, but applies to HTML documents.
=item libhtml
This is the same as C<bindoc> above, but applies to HTML documents.
=back
Four other parameters let you control various aspects of how
installation paths are determined:
=over 4
=item installdirs
The default destinations for these installable things come from
entries in your system's C<Config.pm>. You can select from three
different sets of default locations by setting the C<installdirs>
parameter as follows:
'installdirs' set to:
core site vendor
uses the following defaults from Config.pm:
lib => installprivlib installsitelib installvendorlib
arch => installarchlib installsitearch installvendorarch
script => installscript installsitebin installvendorbin
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 C<installdirs> is "site". If you're creating
vendor distributions of module packages, you may want to do something
like this:
perl Build.PL --installdirs vendor
or
./Build install --installdirs vendor
If you're installing an updated version of a module that was included
with perl itself (i.e. a "core module"), then you may set
C<installdirs> to "core" to overwrite the module in its present
location.
(Note that the 'script' line is different from C<MakeMaker> -
unfortunately there's no such thing as "installsitescript" or
"installvendorscript" entry in C<Config.pm>, so we use the
"installsitebin" and "installvendorbin" entries to at least get the
general location right. In the future, if C<Config.pm> adds some more
appropriate entries, we'll start using those.)
=item install_path
Once the defaults have been set, you can override them.
On the command line, that would look like this:
perl Build.PL --install_path lib=/foo/lib --install_path arch=/foo/lib/arch
or this:
./Build install --install_path lib=/foo/lib --install_path arch=/foo/lib/arch
=item install_base
You can also set the whole bunch of installation paths by supplying the
C<install_base> parameter to point to a directory on your system. For
instance, if you set C<install_base> to "/home/ken" on a Linux
system, you'll install as follows:
lib => /home/ken/lib/perl5
arch => /home/ken/lib/perl5/i386-linux
script => /home/ken/bin
bin => /home/ken/bin
bindoc => /home/ken/man/man1
libdoc => /home/ken/man/man3
binhtml => /home/ken/html
libhtml => /home/ken/html
Note that this is I<different> from how C<MakeMaker>'s C<PREFIX>
parameter works. C<install_base> just gives you a default layout under the
directory you specify, which may have little to do with the
C<installdirs=site> layout.
The exact layout under the directory you specify may vary by system -
we try to do the "sensible" thing on each platform.
=item destdir
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 C<rpm> or C<dpkg> could create a package from), you can
use the C<destdir> parameter:
perl Build.PL --destdir /tmp/foo
or
./Build install --destdir /tmp/foo
This will effectively install to "/tmp/foo/$sitelib",
"/tmp/foo/$sitearch", and the like, except that it will use
C<File::Spec> to make the pathnames work correctly on whatever
platform you're installing on.
=item prefix
Provided for compatibility with C<ExtUtils::MakeMaker>'s PREFIX argument.
C<prefix> should be used when you wish Module::Build to install your
modules, documentation and scripts in the same place
C<ExtUtils::MakeMaker> does.
The following are equivalent.
perl Build.PL --prefix /tmp/foo
perl Makefile.PL PREFIX=/tmp/foo
Because of the very complex nature of the prefixification logic, the
behavior of PREFIX in C<MakeMaker> has changed subtly over time.
Module::Build's --prefix logic is equivalent to the PREFIX logic found
in C<ExtUtils::MakeMaker> 6.30.
If you do not need to retain compatibility with C<ExtUtils::MakeMaker> or
are starting a fresh Perl installation we recommend you use
C<install_base> instead (and C<INSTALL_BASE> in C<ExtUtils::MakeMaker>).
See L<Module::Build::Cookbook/Instaling in the same location as
ExtUtils::MakeMaker> for further information.
=back
=head1 MOTIVATIONS
There are several reasons I wanted to start over, and not just fix
( run in 1.043 second using v1.01-cache-2.11-cpan-63c85eba8c4 )