build.pm

来自「视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.」· PM 代码 · 共 1,072 行 · 第 1/3 页

[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 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 '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_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,
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.

=item realclean

[version 0.01]

This action is just like the C<clean> action, but also removes the
C<_build> directory and the C<Build> script.  If you run the
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> 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>.

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

[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',
    },
    ...

=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<versionlib> 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. --use-rcfile).  Additionally, the argument to boolean options is
optional, and boolean options can be negated by prefixing them with
'no' or 'no-' (e.g. --noverbose or --no-verbose).

=over 4

=item quiet

Suppress informative messages on output.

=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 verbose

Display extra information about the Build on output.

=item allow_mb_mismatch