Alien-ROOT
view release on metacpan or search on metacpan
inc/inc_Module-Build/Module/Build.pm view on Meta::CPAN
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]
Reports which files are skipped due to the entries in the
F<MANIFEST.SKIP> file (See L<manifest> for details)
=item test
[version 0.01]
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
other tests that don't use the C<Test::Harness> format for output.
To override the choice of tests to run, you may pass a C<test_files>
argument whose value is a whitespace-separated list of test scripts to
run. This is especially useful in development, when you only want to
run a single test to see whether you've squashed a certain bug yet:
./Build test --test_files t/something_failing.t
You may also pass several C<test_files> arguments separately:
./Build test --test_files t/one.t --test_files t/two.t
or use a C<glob()>-style pattern:
./Build test --test_files 't/01-*.t'
=item testall
[version 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]
Runs the C<test> action using C<Devel::Cover>, generating a
code-coverage report showing which parts of the code were actually
exercised during the tests.
To pass options to C<Devel::Cover>, set the C<$DEVEL_COVER_OPTIONS>
environment variable:
DEVEL_COVER_OPTIONS=-ignore,Build ./Build testcover
=item testdb
[version 0.05]
This is a synonym for the 'test' action with the C<debugger=1>
argument.
=item testpod
[version 0.25]
This checks all the files described in the C<docs> action and
produces C<Test::Harness>-style output. If you are a module author,
this is useful to run before creating a new release.
=item testpodcoverage
[version 0.28]
This checks the pod coverage of the distribution and
produces C<Test::Harness>-style output. If you are a module author,
this is useful to run before creating a new release.
=item versioninstall
[version 0.16]
** Note: since C<only.pm> is so new, and since we just recently added
support for it here too, this feature is to be considered
experimental. **
If you have the C<only.pm> module installed on your system, you can
use this action to install a module into the version-specific library
trees. This means that you can have several versions of the same
module installed and C<use> a specific one like this:
use only MyModule => 0.55;
To override the default installation libraries in C<only::config>,
specify the C<versionlib> parameter when you run the C<Build.PL> script:
perl Build.PL --versionlib /my/version/place/
To override which version the module is installed as, specify the
C<version> parameter when you run the C<Build.PL> script:
perl Build.PL --version 0.50
See the C<only.pm> documentation for more information on
version-specific installs.
=back
=head1 OPTIONS
=head2 Command Line Options
The following options can be used during any invocation of C<Build.PL>
or the Build script, during any action. For information on other
options specific to an action, see the documentation for the
respective action.
NOTE: There is some preliminary support for options to use the more
familiar long option style. Most options can be preceded with the
C<--> long option prefix, and the underscores changed to dashes
(e.g. C<--use-rcfile>). Additionally, the argument to boolean options is
optional, and boolean options can be negated by prefixing them with
C<no> or C<no-> (e.g. C<--noverbose> or C<--no-verbose>).
=over 4
=item quiet
Suppress informative messages on output.
=item verbose
Display extra information about the Build on output. C<verbose> will
turn off C<quiet>
=item cpan_client
Sets the C<cpan_client> command for use with the C<installdeps> action.
See C<installdeps> for more details.
=item use_rcfile
Load the F<~/.modulebuildrc> option file. This option can be set to
false to prevent the custom resource file from being loaded.
=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). As of 0.3601, a mismatch results in a warning instead of
a fatal error, so this option effectively just suppresses the warning.
=item debug
Prints Module::Build debugging information to STDOUT, such as a trace of
executed build actions.
=back
=head2 Default Options File (F<.modulebuildrc>)
[version 0.28]
When Module::Build starts up, it will look first for a file,
F<$ENV{HOME}/.modulebuildrc>. If it's not found there, it will look
in the the F<.modulebuildrc> file in the directories referred to by
the environment variables C<HOMEDRIVE> + C<HOMEDIR>, C<USERPROFILE>,
C<APPDATA>, C<WINDIR>, C<SYS$LOGIN>. If the file exists, the options
specified there will be used as defaults, as if they were typed on the
command line. The defaults can be overridden by specifying new values
on the command line.
The action name must come at the beginning of the line, followed by any
amount of whitespace and then the options. Options are given the same
as they would be on the command line. They can be separated by any
amount of whitespace, including newlines, as long there is whitespace at
the beginning of each continued line. Anything following a hash mark (C<#>)
is considered a comment, and is stripped before parsing. If more than
( run in 1.105 second using v1.01-cache-2.11-cpan-0068ddc7af1 )