view release on metacpan or  search on metacpan

local/lib/perl5/Module/Build/API.pod  view on Meta::CPAN

  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 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 can_action( $action )

Returns a reference to the method that defines C<$action>, or false
otherwise. This is handy for actions defined (or maybe not!) in subclasses.

[version 0.32_xx]

=item cbuilder()

[version 0.2809]

Returns the internal ExtUtils::CBuilder object that can be used for
compiling & linking C code.  If no such object is available (e.g. if
the system has no compiler installed) an exception will be thrown.

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

  {
   ok => $whether_the_dependency_is_satisfied,
   have => $version_already_installed,
   need => $version_requested, # Same as incoming $version argument
   message => $informative_error_message,
  }

If no version of C<$module> is currently installed, the C<have> value
will be the string C<< "<none>" >>.  Otherwise the C<have> value will
simply be the version of the installed module.  Note that this means
that if C<$module> is installed but doesn't define a version number,
the C<have> value will be C<undef> - this is why we don't use C<undef>
for the case when C<$module> isn't installed at all.

This method may be called either as an object method
(C<< $build->check_installed_status($module, $version) >>)
or as a class method
(C<< Module::Build->check_installed_status($module, $version) >>).

=item check_installed_version($module, $version)

[version 0.05]

Like L<check_installed_status()|/"check_installed_status($module, $version)">,
but simply returns true or false depending on whether module
C<$module> satisfies the dependency C<$version>.

If the check succeeds, the return value is the actual version of
C<$module> installed on the system.  This allows you to do the
following:

  my $installed = $build->check_installed_version('DBI', '1.15');
  if ($installed) {
    print "Congratulations, version $installed of DBI is installed.\n";
  } else {
    die "Sorry, you must install DBI.\n";
  }

If the check fails, we return false and set C<$@> to an informative
error message.

If C<$version> is any non-true value (notably zero) and any version of
C<$module> is installed, we return true.  In this case, if C<$module>
doesn't define a version, or if its version is zero, we return the
special value "0 but true", which is numerically zero, but logically
true.

In general you might prefer to use C<check_installed_status> if you
need detailed information, or this method if you just need a yes/no
answer.

=item compare_versions($v1, $op, $v2)

[version 0.28]

Compares two module versions C<$v1> and C<$v2> using the operator
C<$op>, which should be one of Perl's numeric operators like C<!=> or
C<< >= >> or the like.  We do at least a halfway-decent job of
handling versions that aren't strictly numeric, like C<0.27_02>, but
exotic stuff will likely cause problems.

In the future, the guts of this method might be replaced with a call
out to C<version.pm>.

=item config($key)

=item config($key, $value)

=item config() [deprecated]

[version 0.22]

With a single argument C<$key>, returns the value associated with that
key in the C<Config.pm> hash, including any changes the author or user
has specified.

With C<$key> and C<$value> arguments, sets the value for future
callers of C<config($key)>.

With no arguments, returns a hash reference containing all such
key-value pairs.  This usage is deprecated, though, because it's a
resource hog and violates encapsulation.

=item config_data($name)

=item config_data($name => $value)

[version 0.26]

With a single argument, returns the value of the configuration
variable C<$name>.  With two arguments, sets the given configuration
variable to the given value.  The value may be any Perl scalar that's
serializable with C<Data::Dumper>.  For instance, if you write a
module that can use a MySQL or PostgreSQL back-end, you might create
configuration variables called C<mysql_connect> and
C<postgres_connect>, and set each to an array of connection parameters
for C<< DBI->connect() >>.

Configuration values set in this way using the Module::Build object
will be available for querying during the build/test process and after
installation via the generated C<...::ConfigData> module, as
C<< ...::ConfigData->config($name) >>.

The L<feature()|/"feature($name)"> and C<config_data()> methods represent
Module::Build's main support for configuration of installed modules.
See also L<Module::Build::Authoring/"SAVING CONFIGURATION INFORMATION">.

=item conflicts()

[version 0.21]

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

=item contains_pod($file) [deprecated]

[version 0.20]

[Deprecated] Please see L<Module::Metadata> instead.

Returns true if the given file appears to contain POD documentation.
Currently this checks whether the file has a line beginning with
'=pod', '=head', or '=item', but the exact semantics may change in the
future.

=item copy_if_modified(%parameters)

[version 0.19]

Takes the file in the C<from> parameter and copies it to the file in
the C<to> parameter, or the directory in the C<to_dir> parameter, if
the file has changed since it was last copied (or if it doesn't exist
in the new location).  By default the entire directory structure of
C<from> will be copied into C<to_dir>; an optional C<flatten>
parameter will copy into C<to_dir> without doing so.

Returns the path to the destination file, or C<undef> if nothing
needed to be copied.

Any directories that need to be created in order to perform the
copying will be automatically created.

The destination file is set to read-only. If the source file has the
executable bit set, then the destination file will be made executable.

=item create_build_script()

[version 0.05]

Creates an executable script called C<Build> in the current directory
that will be used to execute further user actions.  This script is
roughly analogous (in function, not in form) to the Makefile created
by C<ExtUtils::MakeMaker>.  This method also creates some temporary