module::build::authoring.3

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

.PP
.Vb 2
\&  \-\-\-\-\-\- in Build.PL: \-\-\-\-\-\-\-\-\-\-
\&  #!/usr/bin/perl
\&
\&  use lib q(/nonstandard/library/path);
\&  use My::Builder;  # Or whatever you want to call it
\&
\&  my $build = My::Builder\->new
\&    (
\&     module_name => \*(AqFoo::Bar\*(Aq,  # All the regular args...
\&     license     => \*(Aqperl\*(Aq,
\&     dist_author => \*(AqA N Other <[e-mail]>\*(Aq,
\&     requires    => { Carp => 0 }
\&    );
\&  $build\->create_build_script;
.Ve
.PP
This is relatively straightforward, and is the best way to do things
if your My::Builder class contains lots of code.  The
\&\f(CW\*(C`create_build_script()\*(C'\fR method will ensure that the current value of
\&\f(CW@INC\fR (including the \f(CW\*(C`/nonstandard/library/path\*(C'\fR) is propogated to
the Build script, so that My::Builder can be found when running build
actions.
.PP
For very small additions, Module::Build provides a \f(CW\*(C`subclass()\*(C'\fR
method that lets you subclass Module::Build more conveniently, without
creating a separate file for your module:
.PP
.Vb 2
\&  \-\-\-\-\-\- in Build.PL: \-\-\-\-\-\-\-\-\-\-
\&  #!/usr/bin/perl
\&
\&  use Module::Build;
\&  my $class = Module::Build\->subclass
\&    (
\&     class => \*(AqMy::Builder\*(Aq,
\&     code => q{
\&       sub ACTION_foo {
\&         print "I\*(Aqm fooing to death!\en";
\&       }
\&     },
\&    );
\&
\&  my $build = $class\->new
\&    (
\&     module_name => \*(AqFoo::Bar\*(Aq,  # All the regular args...
\&     license     => \*(Aqperl\*(Aq,
\&     dist_author => \*(AqA N Other <[e-mail]>\*(Aq,
\&     requires    => { Carp => 0 }
\&    );
\&  $build\->create_build_script;
.Ve
.PP
Behind the scenes, this actually does create a \f(CW\*(C`.pm\*(C'\fR file, since the
code you provide must persist after Build.PL is run if it is to be
very useful.
.PP
See also the documentation for the \*(L"\fIsubclass()\fR\*(R" in Module::Build::API
method.
.SH "PREREQUISITES"
.IX Header "PREREQUISITES"
.Sh "Types of prerequisites"
.IX Subsection "Types of prerequisites"
To specify what versions of other modules are used by this
distribution, several types of prerequisites can be defined with the
following parameters:
.IP "configure_requires" 3
.IX Item "configure_requires"
Items that must be installed \fIbefore\fR configuring this distribution
(i.e. before running the \fIBuild.PL\fR script).  This might be a
specific minimum version of \f(CW\*(C`Module::Build\*(C'\fR or any other module the
\&\fIBuild.PL\fR needs in order to do its stuff.  Clients like \f(CW\*(C`CPAN.pm\*(C'\fR
or \f(CW\*(C`CPANPLUS\*(C'\fR will be expected to pick \f(CW\*(C`configure_requires\*(C'\fR out of the
\&\fI\s-1META\s0.yml\fR file and install these items before running the
\&\f(CW\*(C`Build.PL\*(C'\fR.
.Sp
*TODO* auto-add M::B?  In what circumstances?
.IP "build_requires" 3
.IX Item "build_requires"
Items that are necessary for building and testing this distribution,
but aren't necessary after installation.  This can help users who only
want to install these items temporarily.  It also helps reduce the
size of the \s-1CPAN\s0 dependency graph if everything isn't smooshed into
\&\f(CW\*(C`requires\*(C'\fR.
.IP "requires" 3
.IX Item "requires"
Items that are necessary for basic functioning.
.IP "recommends" 3
.IX Item "recommends"
Items that are recommended for enhanced functionality, but there are
ways to use this distribution without having them installed.  You
might also think of this as \*(L"can use\*(R" or \*(L"is aware of\*(R" or \*(L"changes
behavior in the presence of\*(R".
.IP "conflicts" 3
.IX Item "conflicts"
Items that can cause problems with this distribution when installed.
This is pretty rare.
.Sh "Format of prerequisites"
.IX Subsection "Format of prerequisites"
The prerequisites are given in a hash reference, where the keys are
the module names and the values are version specifiers:
.PP
.Vb 6
\&  requires => {
\&               Foo::Module => \*(Aq2.4\*(Aq,
\&               Bar::Module => 0,
\&               Ken::Module => \*(Aq>= 1.2, != 1.5, < 2.0\*(Aq,
\&               perl => \*(Aq5.6.0\*(Aq
\&              },
.Ve
.PP
The above four version specifiers have different effects.  The value
\&\f(CW\*(Aq2.4\*(Aq\fR means that \fBat least\fR version 2.4 of \f(CW\*(C`Foo::Module\*(C'\fR must be
installed.  The value \f(CW0\fR means that \fBany\fR version of \f(CW\*(C`Bar::Module\*(C'\fR
is acceptable, even if \f(CW\*(C`Bar::Module\*(C'\fR doesn't define a version.  The
more verbose value \f(CW\*(Aq>= 1.2, != 1.5, < 2.0\*(Aq\fR means that
\&\f(CW\*(C`Ken::Module\*(C'\fR's version must be \fBat least\fR 1.2, \fBless than\fR 2.0,
and \fBnot equal to\fR 1.5.  The list of criteria is separated by commas,
and all criteria must be satisfied.
.PP
A special \f(CW\*(C`perl\*(C'\fR entry lets you specify the versions of the Perl
interpreter that are supported by your module.  The same version
dependency-checking semantics are available, except that we also
understand perl's new double-dotted version numbers.
.Sh "\s-1XS\s0 Extensions"
.IX Subsection "XS Extensions"
Modules which need to compile \s-1XS\s0 code should list \f(CW\*(C`ExtUtils::CBuilder\*(C'\fR
as a \f(CW\*(C`build_requires\*(C'\fR element.
.SH "SAVING CONFIGURATION INFORMATION"
.IX Header "SAVING CONFIGURATION INFORMATION"
Module::Build provides a very convenient way to save configuration
information that your installed modules (or your regression tests) can
access.  If your Build process calls the \f(CW\*(C`feature()\*(C'\fR or
\&\f(CW\*(C`config_data()\*(C'\fR methods, then a \f(CW\*(C`Foo::Bar::ConfigData\*(C'\fR module will
automatically be created for you, where \f(CW\*(C`Foo::Bar\*(C'\fR is the
\&\f(CW\*(C`module_name\*(C'\fR parameter as passed to \f(CW\*(C`new()\*(C'\fR.  This module provides
access to the data saved by these methods, and a way to update the
values.  There is also a utility script called \f(CW\*(C`config_data\*(C'\fR
distributed with Module::Build that provides a command line interface
to this same functionality.  See also the generated
\&\f(CW\*(C`Foo::Bar::ConfigData\*(C'\fR documentation, and the \f(CW\*(C`config_data\*(C'\fR
script's documentation, for more information.
.SH "STARTING MODULE DEVELOPMENT"
.IX Header "STARTING MODULE DEVELOPMENT"
When starting development on a new module, it's rarely worth your time
to create a tree of all the files by hand.  Some automatic
module-creators are available: the oldest is \f(CW\*(C`h2xs\*(C'\fR, which has
shipped with perl itself for a long time.  Its name reflects the fact
that modules were originally conceived of as a way to wrap up a C
library (thus the \f(CW\*(C`h\*(C'\fR part) into perl extensions (thus the \f(CW\*(C`xs\*(C'\fR
part).
.PP
These days, \f(CW\*(C`h2xs\*(C'\fR has largely been superseded by modules like
\&\f(CW\*(C`ExtUtils::ModuleMaker\*(C'\fR, and \f(CW\*(C`Module::Starter\*(C'\fR.  They have varying
degrees of support for \f(CW\*(C`Module::Build\*(C'\fR.
.SH "AUTOMATION"
.IX Header "AUTOMATION"
One advantage of Module::Build is that since it's implemented as Perl
methods, you can invoke these methods directly if you want to install
a module non-interactively.  For instance, the following Perl script
will invoke the entire build/install procedure:
.PP
.Vb 4
\&  my $build = Module::Build\->new(module_name => \*(AqMyModule\*(Aq);
\&  $build\->dispatch(\*(Aqbuild\*(Aq);
\&  $build\->dispatch(\*(Aqtest\*(Aq);
\&  $build\->dispatch(\*(Aqinstall\*(Aq);
.Ve
.PP
If any of these steps encounters an error, it will throw a fatal
exception.
.PP
You can also pass arguments as part of the build process:
.PP
.Vb 4
\&  my $build = Module::Build\->new(module_name => \*(AqMyModule\*(Aq);
\&  $build\->dispatch(\*(Aqbuild\*(Aq);
\&  $build\->dispatch(\*(Aqtest\*(Aq, verbose => 1);
\&  $build\->dispatch(\*(Aqinstall\*(Aq, sitelib => \*(Aq/my/secret/place/\*(Aq);
.Ve
.PP
Building and installing modules in this way skips creating the
\&\f(CW\*(C`Build\*(C'\fR script.
.SH "MIGRATION"
.IX Header "MIGRATION"
Note that if you want to provide both a \fIMakefile.PL\fR and a
\&\fIBuild.PL\fR for your distribution, you probably want to add the
following to \f(CW\*(C`WriteMakefile\*(C'\fR in your \fIMakefile.PL\fR so that MakeMaker
doesn't try to run your \fIBuild.PL\fR as a normal \fI.PL\fR file:
.PP
.Vb 1
\&  PL_FILES => {},
.Ve
.PP
You may also be interested in looking at the \f(CW\*(C`Module::Build::Compat\*(C'\fR
module, which can automatically create various kinds of \fIMakefile.PL\fR
compatibility layers.
.SH "AUTHOR"
.IX Header "AUTHOR"
Ken Williams <[e-mail]>
.PP
Development questions, bug reports, and patches should be sent to the
Module-Build mailing list at <module\[e-mail]>.
.PP
Bug reports are also welcome at
<http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module\-Build>.
.PP
The latest development version is available from the Subversion
repository at <https://svn.perl.org/modules/Module\-Build/trunk/>
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fIperl\fR\|(1), Module::Build(3), Module::Build::API(3),
Module::Build::Cookbook(3), ExtUtils::MakeMaker(3), \s-1YAML\s0(3)
.PP
\&\fI\s-1META\s0.yml\fR Specification:
<http://module\-build.sourceforge.net/META\-spec\-current.html>
.PP
<http://www.dsmit.com/cons/>
.PP
<http://search.cpan.org/dist/PerlBuildSystem/>