use vars qw($VERSION @ISA);
@ISA = qw(Module::Build::Base);
-$VERSION = '0.28';
+$VERSION = '0.31012';
$VERSION = eval $VERSION;
# Okay, this is the brute-force method of finding out what kind of
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
sunos Unix
cygwin Unix
os2 Unix
-
+ interix Unix
+ gnu Unix
+ gnukfreebsd Unix
+
dos Windows
MSWin32 Windows
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__
'actions'. In this case the actions run are 'build' (the default
action), 'test', and 'install'. Other actions defined so far include:
- build install
- clean manifest
- code manpages
+ build manifest
+ clean manpages
+ code pardist
config_data ppd
diff ppmdist
dist prereq_report
distcheck pure_install
distclean realclean
- distdir skipcheck
- distmeta test
- distsign testcover
- disttest testdb
- docs testpod
- fakeinstall testpodcoverage
- help versioninstall
- html
+ distdir retest
+ distmeta skipcheck
+ distsign test
+ disttest testall
+ docs testcover
+ fakeinstall testdb
+ help testpod
+ html testpodcoverage
+ install versioninstall
You can run the 'help' action for a complete list of actions.
lifetime of that command. Per-action command line parameters take
precedence over parameters specified at C<perl Build.PL> time.
-The build process also relies heavily on the C<Config.pm> module, and
-all the key=value pairs in C<Config.pm> are available in
-
-C<< $self->{config} >>. If the user wishes to override any of the
+The build process also relies heavily on the C<Config.pm> module.
+If the user wishes to override any of the
values in C<Config.pm>, she may specify them like so:
perl Build.PL --config cc=gcc --config ld=gcc
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-v1.2.html>
+L<http://module-build.sourceforge.net/META-spec-current.html>
=item distsign
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]
[version 0.28]
This action is identical to the C<install> action. In the future,
-though, if C<install> starts writing to the file file
+though, when C<install> starts writing to the file
F<$(INSTALLARCHLIB)/perllocal.pod>, C<pure_install> won't, and that
will be the only difference between them.
C<realclean> action, you are essentially starting over, so you will
have to re-create the C<Build> script again.
+=item retest
+
+[version 0.2806]
+
+This is just like the C<test> action, but doesn't actually build the
+distribution first, and doesn't add F<blib/> to the load path, and
+therefore will test against a I<previously> installed version of the
+distribution. This can be used to verify that a certain installed
+distribution still works, or to see whether newer versions of a
+distribution still pass the old regression tests, and so on.
+
=item skipcheck
[version 0.05]
[version 0.01]
-This will use C<Test::Harness> to run any regression tests and report
-their results. Tests can be defined in the standard places: a file
-called C<test.pl> in the top-level directory, or several files ending
-with C<.t> in a C<t/> directory.
+This will use C<Test::Harness> or C<TAP::Harness> to run any regression
+tests and report their results. Tests can be defined in the standard
+places: a file called C<test.pl> in the top-level directory, or several
+files ending with C<.t> in a C<t/> directory.
If you want tests to be 'verbose', i.e. show details of test execution
rather than just summary information, pass the argument C<verbose=1>.
If you want to run tests under the perl debugger, pass the argument
C<debugger=1>.
+If you want to have Module::Build find test files with different file
+name extensions, pass the C<test_file_exts> argument with an array
+of extensions, such as C<[qw( .t .s .z )]>.
+
+If you want test to be run by C<TAP::Harness>, rather than C<Test::Harness>,
+pass the argument C<tap_harness_args> as an array reference of arguments to
+pass to the TAP::Harness constructor.
+
In addition, if a file called C<visual.pl> exists in the top-level
directory, this file will be executed as a Perl script and its output
will be shown to the user. This is a good place to put speed tests or
./Build test --test_files 't/01-*.t'
+=item testall
+
+[verion 0.2807]
+
+[Note: the 'testall' action and the code snippets below are currently
+in alpha stage, see
+L<"http://www.nntp.perl.org/group/perl.module.build/2007/03/msg584.html"> ]
+
+Runs the C<test> action plus each of the C<test$type> actions defined by
+the keys of the C<test_types> parameter.
+
+Currently, you need to define the ACTION_test$type method yourself and
+enumerate them in the test_types parameter.
+
+ my $mb = Module::Build->subclass(
+ code => q(
+ sub ACTION_testspecial { shift->generic_test(type => 'special'); }
+ sub ACTION_testauthor { shift->generic_test(type => 'author'); }
+ )
+ )->new(
+ ...
+ test_types => {
+ special => '.st',
+ author => ['.at', '.pt' ],
+ },
+ ...
+
=item testcover
[version 0.26]
Display extra information about the Build on output.
+=item allow_mb_mismatch
+
+Suppresses the check upon startup that the version of Module::Build
+we're now running under is the same version that was initially invoked
+when building the distribution (i.e. when the C<Build.PL> script was
+first run). Use with caution.
+
=back
libhtml => /home/ken/html
Note that this is I<different> from how MakeMaker's C<PREFIX>
-parameter works. See L</"Why PREFIX is not recommended"> for more
-details. C<install_base> just gives you a default layout under the
+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.
C<File::Spec> to make the pathnames work correctly on whatever
platform you're installing on.
-=back
-
-
-=head2 About PREFIX Support
-
-[version 0.28]
-
-First, it is necessary to understand the original idea behind
-C<PREFIX>. If, for example, the default installation locations for
-your machine are F</usr/local/lib/perl5/5.8.5> for modules,
-F</usr/local/bin> for executables, F</usr/local/man/man1> and
-F</usr/local/man/man3> for manual pages, etc., then they all share the
-same "prefix" F</usr/local>. MakeMaker's C<PREFIX> mechanism was
-intended as a way to change an existing prefix that happened to occur
-in all those paths - essentially a C<< s{/usr/local}{/foo/bar} >> for
-each path.
-
-However, the real world is more complicated than that. The C<PREFIX>
-idea is fundamentally broken when your machine doesn't jibe with
-C<PREFIX>'s worldview.
-
-
-=over 4
-
-=item Why PREFIX is not recommended
-
-=over 4
-
-=item *
-
-Many systems have Perl configs that make little sense with PREFIX.
-For example, OS X, where core modules go in
-F</System/Library/Perl/...>, user-installed modules go in
-F</Library/Perl/...>, and man pages go in F</usr/share/man/...>. The
-PREFIX is thus set to F</>. Install L<Foo::Bar> on OS X with
-C<PREFIX=/home/spurkis> and you get things like
-F</home/spurkis/Library/Perl/5.8.1/Foo/Bar.pm> and
-F</home/spurkis/usr/share/man/man3/Foo::Bar.3pm>. Not too pretty.
-
-The problem is not limited to Unix-like platforms, either - on Windows
-builds (e.g. ActiveState perl 5.8.0), we have user-installed modules
-going in F<C:\Perl\site\lib>, user-installed executables going in
-F<C:\Perl\bin>, and PREFIX=F<C:\Perl\site>. The prefix just doesn't
-apply neatly to the executables.
-
-=item *
-
-The PREFIX logic is too complicated and hard to predict for the user.
-It's hard to document what exactly is going to happen. You can't give
-a user simple instructions like "run perl Makefile.PL PREFIX=~ and
-then set PERL5LIB=~/lib/perl5".
-
-=item *
-
-The results from PREFIX will change if your configuration of Perl
-changes (for example, if you upgrade Perl). This means your modules
-will end up in different places.
-
-=item *
-
-The results from PREFIX can change with different releases of
-MakeMaker. The logic of PREFIX is subtle and it has been altered in
-the past (mostly to limit damage in the many "edge cases" when its
-behavior was undesirable).
-
-=item *
-
-PREFIX imposes decisions made by the person who configured Perl onto
-the person installing a module. The person who configured Perl could
-have been you or it could have been some guy at Redhat.
-
-=back
-
-
-=item Alternatives to PREFIX
-
-Module::Build offers L</install_base> as a simple, predictable, and
-user-configurable alternative to ExtUtils::MakeMaker's C<PREFIX>.
-What's more, MakeMaker will soon accept C<INSTALL_BASE> -- we strongly
-urge you to make the switch.
-
-Here's a quick comparison of the two when installing modules to your
-home directory on a unix box:
-
-MakeMaker [*]:
-
- % perl Makefile.PL PREFIX=/home/spurkis
- PERL5LIB=/home/spurkis/lib/perl5/5.8.5:/home/spurkis/lib/perl5/site_perl/5.8.5
- PATH=/home/spurkis/bin
- MANPATH=/home/spurkis/man
+=item prefix
-Module::Build:
+Provided for compatibility with 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
+ExtUtils::MakeMaker does.
- % perl Build.PL install_base=/home/spurkis
- PERL5LIB=/home/spurkis/lib/perl5
- PATH=/home/spurkis/bin
- MANPATH=/home/spurkis/man
+The following are equivalent.
-[*] Note that MakeMaker's behaviour cannot be guaranteed in even this
-common scenario, and differs among different versions of MakeMaker.
+ perl Build.PL --prefix /tmp/foo
+ perl Makefile.PL PREFIX=/tmp/foo
-In short, using C<install_base> is similar to the following MakeMaker usage:
+Because of the very complex nature of the prefixification logic, the
+behavior of PREFIX in MakeMaker has changed subtly over time.
+Module::Build's --prefix logic is equivalent to the PREFIX logic found
+in ExtUtils::MakeMaker 6.30.
- perl Makefile.PL PREFIX=/home/spurkis LIB=/home/spurkis/lib/perl5
+If you do not need to retain compatibility with ExtUtils::MakeMaker or
+are starting a fresh Perl installation we recommand you use
+C<install_base> instead (and C<INSTALL_BASE> in ExtUtils::MakeMaker).
+See L<Module::Build::Cookbook/Instaling in the same location as
+ExtUtils::MakeMaker> for further information.
-See L</"INSTALL PATHS"> for details on other
-installation options available and how to configure them.
=back
Ken Williams <kwilliams@cpan.org>
Development questions, bug reports, and patches should be sent to the
-Module-Build mailing list at <module-build-general@lists.sourceforge.net>.
+Module-Build mailing list at <module-build@perl.org>.
Bug reports are also welcome at
<http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build>.
=head1 COPYRIGHT
-Copyright (c) 2001-2005 Ken Williams. All rights reserved.
+Copyright (c) 2001-2006 Ken Williams. All rights reserved.
This library is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
=head1 SEE ALSO
-perl(1), L<Module::Build::Cookbook>(3), L<Module::Build::Authoring>(3),
-L<Module::Build::API>(3), L<ExtUtils::MakeMaker>(3), L<YAML>(3)
+perl(1), L<Module::Build::Cookbook>, L<Module::Build::Authoring>,
+L<Module::Build::API>, L<ExtUtils::MakeMaker>, L<YAML>
F<META.yml> Specification:
-L<http://module-build.sourceforge.net/META-spec-v1.2.html>
+L<http://module-build.sourceforge.net/META-spec-current.html>
L<http://www.dsmit.com/cons/>
projects / p5sagit/p5-mst-13.2.git / blobdiff