module::build::cookbook.3

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

\&    PREFIX=...            \-\-prefix ...
\&    INSTALL_BASE=...      \-\-install_base ...
\&    DESTDIR=...           \-\-destdir ...
\&    LIB=...               \-\-install_path lib=...
\&    INSTALLDIRS=...       \-\-installdirs ...
\&    INSTALLDIRS=perl      \-\-installdirs core
\&    UNINST=...            \-\-uninst ...
\&    INC=...               \-\-extra_compiler_flags ...
\&    POLLUTE=1             \-\-extra_compiler_flags \-DPERL_POLLUTE
.Ve
.PP
For example, if you are currently installing MakeMaker modules with
this command:
.PP
.Vb 3
\&    perl Makefile.PL PREFIX=~
\&    make test
\&    make install UNINST=1
.Ve
.PP
You can install into the same location with Module::Build using this:
.PP
.Vb 3
\&    perl Build.PL \-\-prefix ~
\&    ./Build test
\&    ./Build install \-\-uninst 1
.Ve
.PP
\fI\f(CI\*(C`prefix\*(C'\fI vs \f(CI\*(C`install_base\*(C'\fI\fR
.IX Subsection "prefix vs install_base"
.PP
The behavior of \f(CW\*(C`prefix\*(C'\fR is complicated and depends on
how your Perl is configured.  The resulting installation locations
will vary from machine to machine and even different installations of
Perl on the same machine.  Because of this, it's difficult to document
where \f(CW\*(C`prefix\*(C'\fR will place your modules.
.PP
In contrast, \f(CW\*(C`install_base\*(C'\fR has predictable, easy to explain
installation locations.  Now that Module::Build and MakeMaker both
have \f(CW\*(C`install_base\*(C'\fR there is little reason to use \f(CW\*(C`prefix\*(C'\fR other
than to preserve your existing installation locations.  If you are
starting a fresh Perl installation we encourage you to use
\&\f(CW\*(C`install_base\*(C'\fR.  If you have an existing installation installed via
\&\f(CW\*(C`prefix\*(C'\fR, consider moving it to an installation structure matching
\&\f(CW\*(C`install_base\*(C'\fR and using that instead.
.Sh "Running a single test file"
.IX Subsection "Running a single test file"
\&\f(CW\*(C`Module::Build\*(C'\fR supports running a single test, which enables you to
track down errors more quickly.  Use the following format:
.PP
.Vb 1
\&  ./Build test \-\-test_files t/mytest.t
.Ve
.PP
In addition, you may want to run the test in verbose mode to get more
informative output:
.PP
.Vb 1
\&  ./Build test \-\-test_files t/mytest.t \-\-verbose 1
.Ve
.PP
I run this so frequently that I define the following shell alias:
.PP
.Vb 1
\&  alias t \*(Aq./Build test \-\-verbose 1 \-\-test_files\*(Aq
.Ve
.PP
So then I can just execute \f(CW\*(C`t t/mytest.t\*(C'\fR to run a single test.
.SH "ADVANCED RECIPES"
.IX Header "ADVANCED RECIPES"
.Sh "Making a \s-1CPAN\s0.pm\-compatible distribution"
.IX Subsection "Making a CPAN.pm-compatible distribution"
New versions of \s-1CPAN\s0.pm understand how to use a \fIBuild.PL\fR script,
but old versions don't.  If authors want to help users who have old
versions, some form of \fIMakefile.PL\fR should be supplied.  The easiest
way to accomplish this is to use the \f(CW\*(C`create_makefile_pl\*(C'\fR parameter to
\&\f(CW\*(C`Module::Build\->new()\*(C'\fR in the \f(CW\*(C`Build.PL\*(C'\fR script, which can
create various flavors of \fIMakefile.PL\fR during the \f(CW\*(C`dist\*(C'\fR action.
.PP
As a best practice, we recommend using the \*(L"traditional\*(R" style of
\&\fIMakefile.PL\fR unless your distribution has needs that can't be
accomplished that way.
.PP
The \f(CW\*(C`Module::Build::Compat\*(C'\fR module, which is part of
\&\f(CW\*(C`Module::Build\*(C'\fR's distribution, is responsible for creating these
\&\fIMakefile.PL\fRs.  Please see Module::Build::Compat for the details.
.Sh "Changing the order of the build process"
.IX Subsection "Changing the order of the build process"
The \f(CW\*(C`build_elements\*(C'\fR property specifies the steps \f(CW\*(C`Module::Build\*(C'\fR
will take when building a distribution.  To change the build order,
change the order of the entries in that property:
.PP
.Vb 4
\&  # Process pod files first
\&  my @e = @{$build\->build_elements};
\&  my $i = grep {$e[$_] eq \*(Aqpod\*(Aq} 0..$#e;
\&  unshift @e, splice @e, $i, 1;
.Ve
.PP
Currently, \f(CW\*(C`build_elements\*(C'\fR has the following default value:
.PP
.Vb 1
\&  [qw( PL support pm xs pod script )]
.Ve
.PP
Do take care when altering this property, since there may be
non-obvious (and non-documented!) ordering dependencies in the
\&\f(CW\*(C`Module::Build\*(C'\fR code.
.Sh "Adding new file types to the build process"
.IX Subsection "Adding new file types to the build process"
Sometimes you might have extra types of files that you want to install
alongside the standard types like \fI.pm\fR and \fI.pod\fR files.  For
instance, you might have a \fIBar.dat\fR file containing some data
related to the \f(CW\*(C`Foo::Bar\*(C'\fR module and you'd like for it to end up as
\&\fIFoo/Bar.dat\fR somewhere in perl's \f(CW@INC\fR path so \f(CW\*(C`Foo::Bar\*(C'\fR can
access it easily at runtime.  The following code from a sample
\&\f(CW\*(C`Build.PL\*(C'\fR file demonstrates how to accomplish this:
.PP
.Vb 8
\&  use Module::Build;
\&  my $build = Module::Build\->new
\&    (
\&     module_name => \*(AqFoo::Bar\*(Aq,
\&     ...other stuff here...
\&    );
\&  $build\->add_build_element(\*(Aqdat\*(Aq);
\&  $build\->create_build_script;
.Ve
.PP
This will find all \fI.dat\fR files in the \fIlib/\fR directory, copy them
to the \fIblib/lib/\fR directory during the \f(CW\*(C`build\*(C'\fR action, and install
them during the \f(CW\*(C`install\*(C'\fR action.
.PP
If your extra files aren't located in the \f(CW\*(C`lib/\*(C'\fR directory in your
distribution, you can explicitly say where they are, just as you'd do
with \fI.pm\fR or \fI.pod\fR files:
.PP
.Vb 9
\&  use Module::Build;
\&  my $build = new Module::Build
\&    (
\&     module_name => \*(AqFoo::Bar\*(Aq,
\&     dat_files => {\*(Aqsome/dir/Bar.dat\*(Aq => \*(Aqlib/Foo/Bar.dat\*(Aq},
\&     ...other stuff here...
\&    );
\&  $build\->add_build_element(\*(Aqdat\*(Aq);
\&  $build\->create_build_script;
.Ve
.PP
If your extra files actually need to be created on the user's machine,
or if they need some other kind of special processing, you'll probably
want to subclass \f(CW\*(C`Module::Build\*(C'\fR and create a special method to
process them, named \f(CW\*(C`process_${kind}_files()\*(C'\fR:
.PP
.Vb 10
\&  use Module::Build;
\&  my $class = Module::Build\->subclass(code => <<\*(AqEOF\*(Aq);
\&    sub process_dat_files {
\&      my $self = shift;
\&      ... locate and process *.dat files,
\&      ... and create something in blib/lib/
\&    }
\&  EOF
\&  my $build = $class\->new
\&    (
\&     module_name => \*(AqFoo::Bar\*(Aq,
\&     ...other stuff here...
\&    );
\&  $build\->add_build_element(\*(Aqdat\*(Aq);
\&  $build\->create_build_script;
.Ve
.PP
If your extra files don't go in \fIlib/\fR but in some other place, see
\&\*(L"Adding new elements to the install process\*(R" for how to actually
get them installed.
.PP
Please note that these examples use some capabilities of Module::Build
that first appeared in version 0.26.  Before that it could
still be done, but the simple cases took a bit more work.
.Sh "Adding new elements to the install process"
.IX Subsection "Adding new elements to the install process"
By default, Module::Build creates seven subdirectories of the \fIblib\fR
directory during the build process: \fIlib\fR, \fIarch\fR, \fIbin\fR,
\&\fIscript\fR, \fIbindoc\fR, \fIlibdoc\fR, and \fIhtml\fR (some of these may be
missing or empty if there's nothing to go in them).  Anything copied
to these directories during the build will eventually be installed
during the \f(CW\*(C`install\*(C'\fR action (see \*(L"\s-1INSTALL\s0 \s-1PATHS\s0\*(R" in Module::Build.
.PP
If you need to create a new custom type of installable element, e.g. \f(CW\*(C`conf\*(C'\fR,
then you need to tell Module::Build where things in \fIblib/conf/\fR
should be installed.  To do this, use the \f(CW\*(C`install_path\*(C'\fR parameter to
the \f(CW\*(C`new()\*(C'\fR method:
.PP
.Vb 5
\&  my $build = Module::Build\->new
\&    (
\&     ...other stuff here...
\&     install_path => { conf => $installation_path }
\&    );
.Ve
.PP
Or you can call the \f(CW\*(C`install_path()\*(C'\fR method later:
.PP
.Vb 1
\&  $build\->install_path(conf => $installation_path);
.Ve
.PP
The user may also specify the path on the command line:
.PP
.Vb 1
\&  perl Build.PL \-\-install_path conf=/foo/path/etc
.Ve
.PP
The important part, though, is that \fIsomehow\fR the install path needs
to be set, or else nothing in the \fIblib/conf/\fR directory will get
installed, and a runtime error during the \f(CW\*(C`install\*(C'\fR action will
result.
.PP
See also \*(L"Adding new file types to the build process\*(R" for how to
create the stuff in \fIblib/conf/\fR in the first place.
.SH "EXAMPLES ON CPAN"
.IX Header "EXAMPLES ON CPAN"
Several distributions on \s-1CPAN\s0 are making good use of various features
of Module::Build.  They can serve as real-world examples for others.
.Sh "SVN-Notify-Mirror"
.IX Subsection "SVN-Notify-Mirror"
<http://search.cpan.org/~jpeacock/SVN\-Notify\-Mirror/>
.PP
John Peacock, author of the \f(CW\*(C`SVN\-Notify\-Mirror\*(C'\fR distribution, says:
.ie n .IP "1. Using ""auto_features"", I check to see whether two optional modules are available \- SVN::Notify::Config and Net::SSH;" 4
.el .IP "1. Using \f(CWauto_features\fR, I check to see whether two optional modules are available \- SVN::Notify::Config and Net::SSH;" 4
.IX Item "1. Using auto_features, I check to see whether two optional modules are available - SVN::Notify::Config and Net::SSH;"
.PD 0
.ie n .IP "2. If the S::N::Config module is loaded, I automatically generate testfiles for it during Build (using the ""PL_files"" property)." 4
.el .IP "2. If the S::N::Config module is loaded, I automatically generate testfiles for it during Build (using the \f(CWPL_files\fR property)." 4
.IX Item "2. If the S::N::Config module is loaded, I automatically generate testfiles for it during Build (using the PL_files property)."
.ie n .IP "3. If the ""ssh_feature"" is available, I ask if the user wishes to perform the ssh tests (since it requires a little preliminary setup);" 4
.el .IP "3. If the \f(CWssh_feature\fR is available, I ask if the user wishes to perform the ssh tests (since it requires a little preliminary setup);" 4
.IX Item "3. If the ssh_feature is available, I ask if the user wishes to perform the ssh tests (since it requires a little preliminary setup);"
.ie n .IP "4. Only if the user has ""ssh_feature"" and answers yes to the testing, do I generate a test file." 4
.el .IP "4. Only if the user has \f(CWssh_feature\fR and answers yes to the testing, do I generate a test file." 4
.IX Item "4. Only if the user has ssh_feature and answers yes to the testing, do I generate a test file."
.PD
I'm sure I could not have handled this complexity with \s-1EU::MM\s0, but it
was very easy to do with M::B.
.Sh "Modifying an action"
.IX Subsection "Modifying an action"
Sometimes you might need an to have an action, say \f(CW\*(C`./Build install\*(C'\fR,
do something unusual.  For instance, you might need to change the
ownership of a file or do something else peculiar to your application.
.PP
You can subclass \f(CW\*(C`Module::Build\*(C'\fR on the fly using the \f(CW\*(C`subclass()\*(C'\fR
method and override the methods that perform the actions.  You may
need to read through \f(CW\*(C`Module::Build::Authoring\*(C'\fR and
\&\f(CW\*(C`Module::Build::API\*(C'\fR to find the methods you want to override.  All
\&\*(L"action\*(R" methods are implemented by a method called \*(L"\s-1ACTION_\s0\*(R" followed
by the action's name, so here's an example of how it would work for
the \f(CW\*(C`install\*(C'\fR action:
.PP
.Vb 5
\&  # Build.PL
\&  use Module::Build;
\&  my $class = Module::Build\->subclass(
\&      class => "Module::Build::Custom",
\&      code => <<\*(AqSUBCLASS\*(Aq );
\&
\&  sub ACTION_install {
\&      my $self = shift;
\&      # YOUR CODE HERE
\&      $self\->SUPER::ACTION_install;
\&  }
\&  SUBCLASS
\&
\&  $class\->new(
\&      module_name => \*(AqYour::Module\*(Aq,
\&      # rest of the usual Module::Build parameters
\&  )\->create_build_script;
.Ve
.SH "AUTHOR"
.IX Header "AUTHOR"
Ken Williams <[e-mail]>
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
Copyright (c) 2001\-2006 Ken Williams.  All rights reserved.
.PP
This library is free software; you can redistribute it and/or
modify it under the same terms as Perl itself.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fIperl\fR\|(1), Module::Build(3), Module::Build::Authoring(3),
Module::Build::API(3)
.SH "POD ERRORS"
.IX Header "POD ERRORS"
Hey! \fBThe above document had some coding errors, which are explained below:\fR
.IP "Around line 395:" 4
.IX Item "Around line 395:"
=back doesn't take any parameters, but you said =back 4