Alien-V8
view release on metacpan or search on metacpan
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
package Module::Build;
# This module doesn't do much of anything itself, it inherits from the
# modules that do the real work. The only real thing it has to do is
# figure out which OS-specific module to pull in. Many of the
# OS-specific modules don't do anything either - most of the work is
# done in Module::Build::Base.
use strict;
use File::Spec ();
use File::Path ();
use File::Basename ();
use Module::Build::Base;
use vars qw($VERSION @ISA);
@ISA = qw(Module::Build::Base);
$VERSION = '0.3603';
$VERSION = eval $VERSION;
# Okay, this is the brute-force method of finding out what kind of
# platform we're on. I don't know of a systematic way. These values
# came from the latest (bleadperl) perlport.pod.
my %OSTYPES = qw(
aix Unix
bsdos Unix
dgux Unix
dragonfly Unix
dynixptx Unix
freebsd Unix
linux Unix
haiku Unix
hpux Unix
irix Unix
darwin Unix
machten Unix
midnightbsd Unix
mirbsd Unix
next Unix
openbsd Unix
netbsd Unix
dec_osf Unix
nto Unix
svr4 Unix
svr5 Unix
sco_sv Unix
unicos Unix
unicosmk Unix
solaris Unix
sunos Unix
cygwin Unix
os2 Unix
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
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
Reports which files are in the build directory but not in the
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
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
=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
( run in 1.873 second using v1.01-cache-2.11-cpan-64ef6c95b5d )