api.pod

source of perl for linux application,

The distribution is licensed under the Artistic License, as specified
by the F<Artistic> file in the standard Perl distribution.

=item artistic_2

The distribution is licensed under the Artistic 2.0 License
(L<http://opensource.org/licenses/artistic-license-2.0.php>.)

=item bsd

The distribution is licensed under the BSD License
(L<http://www.opensource.org/licenses/bsd-license.php>).

=item gpl

The distribution is licensed under the terms of the GNU General
Public License (L<http://www.opensource.org/licenses/gpl-license.php>).

=item lgpl

The distribution is licensed under the terms of the GNU Lesser
General Public License
(L<http://www.opensource.org/licenses/lgpl-license.php>).

=item mit

The distribution is licensed under the MIT License
(L<http://opensource.org/licenses/mit-license.php>).

=item mozilla

The distribution is licensed under the Mozilla Public
License.  (L<http://opensource.org/licenses/mozilla1.0.php> or
L<http://opensource.org/licenses/mozilla1.1.php>)

=item open_source

The distribution is licensed under some other Open Source
Initiative-approved license listed at
L<http://www.opensource.org/licenses/>.

=item perl

The distribution may be copied and redistributed under the same terms
as Perl itself (this is by far the most common licensing option for
modules on CPAN).  This is a dual license, in which the user may
choose between either the GPL or the Artistic license.

=item restrictive

The distribution may not be redistributed without special permission
from the author and/or copyright holder.

=item unrestricted

The distribution is licensed under a license that is B<not> approved
by www.opensource.org but that allows distribution without
restrictions.

=back


Note that you must still include the terms of your license in your
documentation - this field only lets automated tools figure out your
licensing restrictions.  Humans still need something to read.  If you
choose to provide this field, you should make sure that you keep it in
sync with your written documentation if you ever change your licensing
terms.

It is a fatal error to use a license other than the ones mentioned
above.  This is not because I wish to impose licensing terms on you -
please let me know if you would like another license option to be
added to the list.  You may also use a license type of C<unknown> if
you don't wish to specify your terms (but this is usually not a good
idea for you to do!).

I just started out with a small set of licenses to keep things simple,
figuring I'd let people with actual working knowledge in this area
tell me what to do.  So if that's you, drop me a line.

=item meta_add

[version 0.28]

A hash of key/value pairs that should be added to the F<META.yml> file
during the C<distmeta> action.  Any existing entries with the same
names will be overridden.

See the L</"MODULE METADATA"> section for details.

=item meta_merge

[version 0.28]

A hash of key/value pairs that should be merged into the F<META.yml>
file during the C<distmeta> action.  Any existing entries with the
same names will be overridden.

The only difference between C<meta_add> and C<meta_merge> is their
behavior on hash-valued and array-valued entries: C<meta_add> will
completely blow away the existing hash or array value, but
C<meta_merge> will merge the supplied data into the existing hash or
array value.

See the L</"MODULE METADATA"> section for details.

=item module_name

[version 0.03]

The C<module_name> is a shortcut for setting default values of
C<dist_name> and C<dist_version_from>, reflecting the fact that the
majority of CPAN distributions are centered around one "main" module.
For instance, if you set C<module_name> to C<Foo::Bar>, then
C<dist_name> will default to C<Foo-Bar> and C<dist_version_from> will
default to C<lib/Foo/Bar.pm>.  C<dist_version_from> will in turn be
used to set C<dist_version>.

Setting C<module_name> won't override a C<dist_*> parameter you
specify explicitly.

=item PL_files

[version 0.06]

An optional parameter specifying a set of C<.PL> files in your
distribution.  These will be run as Perl scripts prior to processing
the rest of the files in your distribution.  They are usually used as
templates for creating other files dynamically, so that a file like
C<lib/Foo/Bar.pm.PL> might create the file C<lib/Foo/Bar.pm>.

The files are specified with the C<.PL> files as hash keys, and the
file(s) they generate as hash values, like so:

  my $build = Module::Build->new
    (
     module_name => 'Foo::Bar',
     ...
     PL_files => { 'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm' },
    );

Note that the path specifications are I<always> given in Unix-like
format, not in the style of the local system.

If your C<.PL> scripts don't create any files, or if they create files
with unexpected names, or even if they create multiple files, you can
indicate that so that Module::Build can properly handle these created
files:

  PL_files => {
               'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm',
               'lib/something.PL'  => ['/lib/something', '/lib/else'],
               'lib/funny.PL'      => [],
              }

=item pm_files

[version 0.19]

An optional parameter specifying the set of C<.pm> files in this
distribution, specified as a hash reference whose keys are the files'
locations in the distributions, and whose values are their logical
locations based on their package name, i.e. where they would be found
in a "normal" Module::Build-style distribution.  This parameter is
mainly intended to support alternative layouts of files.

For instance, if you have an old-style MakeMaker distribution for a
module called C<Foo::Bar> and a F<Bar.pm> file at the top level of the
distribution, you could specify your layout in your C<Build.PL> like
this:

  my $build = Module::Build->new
    (
     module_name => 'Foo::Bar',
     ...
     pm_files => { 'Bar.pm' => 'lib/Foo/Bar.pm' },
    );

Note that the values should include C<lib/>, because this is where
they would be found in a "normal" Module::Build-style distribution.

Note also that the path specifications are I<always> given in
Unix-like format, not in the style of the local system.

=item pod_files

[version 0.19]

Just like C<pm_files>, but used for specifying the set of C<.pod>
files in your distribution.

=item recommends

[version 0.08]

This is just like the L</requires> argument, except that modules listed
in this section aren't essential, just a good idea.  We'll just print
a friendly warning if one of these modules aren't found, but we'll
continue running.

If a module is recommended but not required, all tests should still
pass if the module isn't installed.  This may mean that some tests
may be skipped if recommended dependencies aren't present.

Automated tools like CPAN.pm should inform the user when recommended
modules aren't installed, and it should offer to install them if it
wants to be helpful.

See the documentation for L<Module::Build::Authoring/"PREREQUISITES">
for the details of how requirements can be specified.

=item recursive_test_files

[version 0.28]

Normally, C<Module::Build> does not search subdirectories when looking
for tests to run. When this options is set it will search recursively
in all subdirectories of the standard 't' test directory.

=item requires

[version 0.07]

An optional C<requires> argument specifies any module prerequisites
that the current module depends on.

One note: currently C<Module::Build> doesn't actually I<require> the
user to have dependencies installed, it just strongly urges.  In the
future we may require it.  There's also a L</recommends> section for
things that aren't absolutely required.

Automated tools like CPAN.pm should refuse to install a module if one
of its dependencies isn't satisfied, unless a "force" command is given
by the user.  If the tools are helpful, they should also offer to
install the dependencies.

A synonym for C<requires> is C<prereq>, to help succour people
transitioning from C<ExtUtils::MakeMaker>.  The C<requires> term is
preferred, but the C<prereq> term will remain valid in future
distributions.

See the documentation for L<Module::Build::Authoring/"PREREQUISITES">
for the details of how requirements can be specified.

=item script_files

[version 0.18]

An optional parameter specifying a set of files that should be
installed as executable Perl scripts when the module is installed.
May be given as an array reference of the files, or as a hash
reference whose keys are the files (and whose values will currently be
ignored).

The default is to install no script files - in other words, there is
no default location where Module::Build will look for script files to
install.

For backward compatibility, you may use the parameter C<scripts>
instead of C<script_files>.  Please consider this usage deprecated,
though it will continue to exist for several version releases.

=item sign

[version 0.16]

If a true value is specified for this parameter, L<Module::Signature>
will be used (via the 'distsign' action) to create a SIGNATURE file
for your distribution during the 'distdir' action, and to add the
SIGNATURE file to the MANIFEST (therefore, don't add it yourself).

The default value is false.  In the future, the default may change to
true if you have C<Module::Signature> installed on your system.

=item test_files

[version 0.23]

An optional parameter specifying a set of files that should be used as
C<Test::Harness>-style regression tests to be run during the C<test>
action.  May be given as an array reference of the files, or as a hash
reference whose keys are the files (and whose values will currently be
ignored).  If the argument is given as a single string (not in an
array reference), that string will be treated as a C<glob()> pattern
specifying the files to use.

The default is to look for a F<test.pl> script in the top-level
directory of the distribution, and any files matching the glob pattern
C<*.t> in the F<t/> subdirectory.  If the C<recursive_test_files>
property is true, then the C<t/> directory will be scanned recursively
for C<*.t> files.


=item xs_files

[version 0.19]

Just like C<pm_files>, but used for specifying the set of C<.xs>
files in your distribution.

=back


=item new_from_context(%args)

[version 0.28]

When called from a directory containing a F<Build.PL> script and a
F<META.yml> file (in other words, the base directory of a
distribution), this method will run the F<Build.PL> and return the
resulting C<Module::Build> object to the caller.  Any key-value
arguments given to C<new_from_context()> are essentially like
command line arguments given to the F<Build.PL> script, so for example
you could pass C<< verbose => 1 >> to this method to turn on
verbosity.

=item resume()

[version 0.03]

You'll probably never call this method directly, it's only called from
the auto-generated C<Build> script.  The C<new()> method is only
called once, when the user runs C<perl Build.PL>.  Thereafter, when
the user runs C<Build test> or another action, the C<Module::Build>
object is created using the C<resume()> method to re-instantiate with
the settings given earlier to C<new()>.

=item subclass()

[version 0.06]

This creates a new C<Module::Build> subclass on the fly, as described
in the L<Module::Build::Authoring/"SUBCLASSING"> section.  The caller
must provide either a C<class> or C<code> parameter, or both.  The
C<class> parameter indicates the name to use for the new subclass, and
defaults to C<MyModuleBuilder>.  The C<code> parameter specifies Perl
code to use as the body of the subclass.

=back


=head2 METHODS

=over 4

=item add_build_element($type)

[version 0.26]

Adds a new type of entry to the build process.  Accepts a single
string specifying its type-name.  There must also be a method defined
to process things of that type, e.g. if you add a build element called
C<'foo'>, then you must also define a method called
C<process_foo_files()>.

See also
L<Module::Build::Cookbook/"Adding new file types to the build process">.

=item add_to_cleanup(@files)

[version 0.03]

You may call C<< $self->add_to_cleanup(@patterns) >> to tell
C<Module::Build> that certain files should be removed when the user
performs the C<Build clean> action.  The arguments to the method are
patterns suitable for passing to Perl's C<glob()> function, specified
in either Unix format or the current machine's native format.  It's
usually convenient to use Unix format when you hard-code the filenames
(e.g. in F<Build.PL>) and the native format when the names are
programmatically generated (e.g. in a testing script).

I decided to provide a dynamic method of the C<$build> object, rather
than just use a static list of files named in the F<Build.PL>, because
these static lists can get difficult to manage.  I usually prefer to
keep the responsibility for registering temporary files close to the
code that creates them.

=item args()

[version 0.26]

  my $args_href = $build->args;
  my %args = $build->args;
  my $arg_value = $build->args($key);
  $build->args($key, $value);

This method is the preferred interface for retrieving the arguments passed via
command line options to F<Build.PL> or F<Build>, minus the Module-Build
specific options.

When called in in a scalar context with no arguments, this method returns a
reference to the hash storing all of the arguments; in an array context, it
returns the hash itself.  When passed a single argument, it returns the value
stored in the args hash for that option key.  When called with two arguments,
the second argument is assigned to the args hash under the key passed as the
first argument.

=item autosplit_file($from, $to)

[version 0.28]

Invokes the L<AutoSplit> module on the C<$from> file, sending the
output to the C<lib/auto> directory inside C<$to>.  C<$to> is
typically the C<blib/> directory.

=item base_dir()

[version 0.14]

Returns a string containing the root-level directory of this build,
i.e. where the C<Build.PL> script and the C<lib> directory can be
found.  This is usually the same as the current working directory,
because the C<Build> script will C<chdir()> into this directory as
soon as it begins execution.

=item build_requires()

[version 0.21]

Returns a hash reference indicating the C<build_requires>
prerequisites that were passed to the C<new()> method.

=item check_installed_status($module, $version)

[version 0.11]

This method returns a hash reference indicating whether a version
dependency on a certain module is satisfied.  The C<$module> argument
is given as a string like C<"Data::Dumper"> or C<"perl">, and the
C<$version> argument can take any of the forms described in L</requires>
above.  This allows very fine-grained version checking.

The returned hash reference has the following structure: