view release on metacpan or  search on metacpan

inc/inc_Module-Build/Module/Build/API.pod  view on Meta::CPAN

  ...

The way the C<current()> method is currently implemented, there may be
slight differences between the C<$build> object in Build.PL and the
one in C<t/colortest.t>.  It is our goal to minimize these differences
in future releases of Module::Build, so please report any anomalies
you find.

One important caveat: in its current implementation, C<current()> will
B<NOT> work correctly if you have changed out of the directory that
C<Module::Build> was invoked from.

=item new()

[version 0.03]

Creates a new Module::Build object.  Arguments to the new() method are
listed below.  Most arguments are optional, but you must provide
either the L</module_name> argument, or L</dist_name> and one of
L</dist_version> or L</dist_version_from>.  In other words, you must
provide enough information to determine both a distribution name and
version.


=over 4

=item add_to_cleanup

[version 0.19]

An array reference of files to be cleaned up when the C<clean> action
is performed. See also the L<add_to_cleanup()|/"add_to_cleanup(@files)">
method.

=item auto_configure_requires

[version 0.34]

This parameter determines whether Module::Build will add itself
automatically to configure_requires (and build_requires) if Module::Build
is not already there.  The required version will be the last 'major' release,
as defined by the decimal version truncated to two decimal places (e.g. 0.34,
instead of 0.3402).  The default value is true.

=item auto_features

[version 0.26]

This parameter supports the setting of features (see
L</feature($name)>) automatically based on a set of prerequisites.  For
instance, for a module that could optionally use either MySQL or
PostgreSQL databases, you might use C<auto_features> like this:

  my $build = Module::Build->new
    (
     ...other stuff here...
     auto_features => {
       pg_support    => {
                         description => "Interface with Postgres databases",
                         requires    => { 'DBD::Pg' => 23.3,
                                          'DateTime::Format::Pg' => 0 },
                        },
       mysql_support => {
                         description => "Interface with MySQL databases",
                         requires    => { 'DBD::mysql' => 17.9,
                                          'DateTime::Format::MySQL' => 0 },
                        },
     }
    );

For each feature named, the required prerequisites will be checked, and
if there are no failures, the feature will be enabled (set to C<1>).
Otherwise the failures will be displayed to the user and the feature
will be disabled (set to C<0>).

See the documentation for L</requires> for the details of how
requirements can be specified.

=item autosplit

[version 0.04]

An optional C<autosplit> argument specifies a file which should be run
through the L<AutoSplit::autosplit()|AutoSplit/autosplit> function.
If multiple files should be split, the argument may be given as an
array of the files to split.

In general I don't consider autosplitting a great idea, because it's
not always clear that autosplitting achieves its intended performance
benefits.  It may even harm performance in environments like mod_perl,
where as much as possible of a module's code should be loaded during
startup.

=item build_class

[version 0.28]

The Module::Build class or subclass to use in the build script.
Defaults to "Module::Build" or the class name passed to or created by
a call to L</subclass()>.  This property is useful if you're
writing a custom Module::Build subclass and have a bootstrapping
problem--that is, your subclass requires modules that may not be
installed when C<perl Build.PL> is executed, but you've listed in
L</build_requires> so that they should be available when C<./Build> is
executed.

=item build_requires

[version 0.07]

Modules listed in this section are necessary to build and install the
given module, but are not necessary for regular usage of it.  This is
actually an important distinction - it allows for tighter control over
the body of installed modules, and facilitates correct dependency
checking on binary/packaged distributions of the module.

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

=item configure_requires

[version 0.30]

Modules listed in this section must be installed I<before> configuring
this distribution (i.e. before running the F<Build.PL> script).
This might be a specific minimum version of C<Module::Build> or any