view release on metacpan or  search on metacpan

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

set this directly, they can use C<module_name> to set C<dist_name> to
a reasonable default.  However, some agglomerative distributions like
C<libwww-perl> or C<bioperl> have names that don't correspond directly
to a module name, so C<dist_name> can be set independently.

=item dist_suffix

[version 0.37]

Specifies an optional suffix to include after the version number
in the distribution directory (and tarball) name.  The only suffix
currently recognized by PAUSE is 'TRIAL', which indicates that the
distribution should not be indexed.  For example:

  Foo-Bar-1.23-TRIAL.tar.gz

This will automatically do the "right thing" depending on C<dist_version> and
C<release_status>.  When C<dist_version> does not have an underscore and
C<release_status> is not 'stable', then C<dist_suffix> will default to 'TRIAL'.
Otherwise it will default to the empty string, disabling the suffix.  

In general, authors should only set this if they B<must> override the default
behavior for some particular purpose.

=item dist_version

[version 0.11]

Specifies a version number for the distribution.  See L</module_name>
or L</dist_version_from> for ways to have this set automatically from a
C<$VERSION> variable in a module.  One way or another, a version
number needs to be set.

=item dist_version_from

[version 0.11]

Specifies a file to look for the distribution version in.  Most
authors won't need to set this directly, they can use L</module_name>
to set it to a reasonable default.

The version is extracted from the specified file according to the same
rules as L<ExtUtils::MakeMaker> and C<CPAN.pm>.  It involves finding
the first line that matches the regular expression

   /([\$*])(([\w\:\']*)\bVERSION)\b.*\=/

eval()-ing that line, then checking the value of the C<$VERSION>
variable.  Quite ugly, really, but all the modules on CPAN depend on
this process, so there's no real opportunity to change to something
better.

If the target file of L</dist_version_from> contains more than one package
declaration, the version returned will be the one matching the configured
L</module_name>.

=item dynamic_config

[version 0.07]

A boolean flag indicating whether the F<Build.PL> file must be
executed, or whether this module can be built, tested and installed
solely from consulting its metadata file.  The main reason to set this
to a true value is that your module performs some dynamic
configuration as part of its build/install process.  If the flag is
omitted, the F<META.yml> spec says that installation tools should
treat it as 1 (true), because this is a safer way to behave.

Currently C<Module::Build> doesn't actually do anything with this flag
- it's up to higher-level tools like C<CPAN.pm> to do something useful
with it.  It can potentially bring lots of security, packaging, and
convenience improvements.

=item extra_compiler_flags

=item extra_linker_flags

[version 0.19]

These parameters can contain array references (or strings, in which
case they will be split into arrays) to pass through to the compiler
and linker phases when compiling/linking C code.  For example, to tell
the compiler that your code is C++, you might do:

  my $build = Module::Build->new
    (
     module_name          => 'Foo::Bar',
     extra_compiler_flags => ['-x', 'c++'],
    );

To link your XS code against glib you might write something like:

  my $build = Module::Build->new
    (
     module_name          => 'Foo::Bar',
     dynamic_config       => 1,
     extra_compiler_flags => scalar `glib-config --cflags`,
     extra_linker_flags   => scalar `glib-config --libs`,
    );

=item get_options

[version 0.26]

You can pass arbitrary command line options to F<Build.PL> or
F<Build>, and they will be stored in the Module::Build object and can
be accessed via the L</args()> method.  However, sometimes you want
more flexibility out of your argument processing than this allows.  In
such cases, use the C<get_options> parameter to pass in a hash
reference of argument specifications, and the list of arguments to
F<Build.PL> or F<Build> will be processed according to those
specifications before they're passed on to C<Module::Build>'s own
argument processing.

The supported option specification hash keys are:


=over 4

=item type

The type of option.  The types are those supported by Getopt::Long; consult
its documentation for a complete list.  Typical types are C<=s> for strings,
C<+> for additive options, and C<!> for negatable options.  If the
type is not specified, it will be considered a boolean, i.e. no
argument is taken and a value of 1 will be assigned when the option is
encountered.

=item store

A reference to a scalar in which to store the value passed to the option.
If not specified, the value will be stored under the option name in the
hash returned by the C<args()> method.

=item default

A default value for the option.  If no default value is specified and no option
is passed, then the option key will not exist in the hash returned by
C<args()>.

=back


You can combine references to your own variables or subroutines with
unreferenced specifications, for which the result will also be stored in the
hash returned by C<args()>.  For example:

  my $loud = 0;
  my $build = Module::Build->new
    (
     module_name => 'Foo::Bar',
     get_options => {
                     Loud =>     { store => \$loud },
                     Dbd  =>     { type  => '=s'   },
                     Quantity => { type  => '+'    },
                    }
    );

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

[version 0.03]

Invokes the build action C<$action>.  Optionally, a list of options
and their values can be passed in.  This is equivalent to invoking an
action at the command line, passing in a list of options.

Custom options that have not been registered must be passed in as a
hash reference in a key named "args":

  $build->dispatch('foo', verbose => 1, args => { my_option => 'value' });

This method is intended to be used to programmatically invoke build
actions, e.g. by applications controlling Module::Build-based builds
rather than by subclasses.

See also L<depends_on()|/"depends_on(@actions)">.  The main
distinction between the two is that C<depends_on()> is meant to call
an action from inside another action, whereas C<dispatch()> is meant
to set the very top action in motion.

=item dist_dir()

[version 0.28]

Returns the name of the directory that will be created during the
C<dist> action.  The name is derived from the C<dist_name> and
C<dist_version> properties.

=item dist_name()

[version 0.21]

Returns the name of the current distribution, as passed to the
C<new()> method in a C<dist_name> or modified C<module_name>
parameter.

=item dist_version()

[version 0.21]

Returns the version of the current distribution, as determined by the
C<new()> method from a C<dist_version>, C<dist_version_from>, or
C<module_name> parameter.

=item do_system($cmd, @args)

[version 0.21]

This is a fairly simple wrapper around Perl's C<system()> built-in
command.  Given a command and an array of optional arguments, this
method will print the command to C<STDOUT>, and then execute it using
Perl's C<system()>.  It returns true or false to indicate success or
failure (the opposite of how C<system()> works, but more intuitive).

Note that if you supply a single argument to C<do_system()>, it
will/may be processed by the system's shell, and any special
characters will do their special things.  If you supply multiple
arguments, no shell will get involved and the command will be executed
directly.

=item extra_compiler_flags()

=item extra_compiler_flags(@flags)

[version 0.25]

Set or retrieve the extra compiler flags. Returns an arrayref of flags.

=item extra_linker_flags()

=item extra_linker_flags(@flags)

[version 0.25]

Set or retrieve the extra linker flags. Returns an arrayref of flags.

=item feature($name)

=item feature($name => $value)

[version 0.26]

With a single argument, returns true if the given feature is set.
With two arguments, sets the given feature to the given boolean value.
In this context, a "feature" is any optional functionality of an
installed module.  For instance, if you write a module that could
optionally support a MySQL or PostgreSQL backend, you might create
features called C<mysql_support> and C<postgres_support>, and set them
to true/false depending on whether the user has the proper databases
installed and configured.

Features 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->feature($name) >>.

The C<feature()> 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 fix_shebang_line(@files)

[version 0.??]

Modify any "shebang" line in the specified files to use the path to the
perl executable being used for the current build.  Files are modified
in-place.  The existing shebang line must have a command that contains
"C<perl>"; arguments to the command do not count.  In particular, this
means that the use of C<#!/usr/bin/env perl> will not be changed.

For an explanation of shebang lines, see
L<http://en.wikipedia.org/wiki/Shebang_%28Unix%29>.

=item have_c_compiler()

[version 0.21]

Returns true if the current system seems to have a working C compiler.
We currently determine this by attempting to compile a simple C source
file and reporting whether the attempt was successful.

=item install_base_relpaths()

=item install_base_relpaths($type)

=item install_base_relpaths($type => $path)

[version 0.28]

Set or retrieve the relative paths that are appended to
C<install_base> for any installable element. This is useful if you
want to set the relative install path for custom build elements.

With no argument, it returns a reference to a hash containing all
elements and their respective values. This hash should not be modified