view release on metacpan or  search on metacpan

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

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
data in a directory called C<_build/>.  Both of these will be removed
when the C<realclean> action is performed.

Among the files created in C<_build/> is a F<_build/prereqs> file
containing the set of prerequisites for this distribution, as a hash
of hashes.  This file may be C<eval()>-ed to obtain the authoritative
set of prerequisites, which might be different from the contents of
F<META.yml> (because F<Build.PL> might have set them dynamically).
But fancy developers take heed: do not put any fancy custom runtime
code in the F<_build/prereqs> file, leave it as a static declaration
containing only strings and numbers.  Similarly, do not alter the
structure of the internal C<< $self->{properties}{requires} >> (etc.)
data members, because that's where this data comes from.

=item current_action()

[version 0.28]

Returns the name of the currently-running action, such as "build" or
"test".  This action is not necessarily the action that was originally
invoked by the user.  For example, if the user invoked the "test"
action, current_action() would initially return "test".  However,
action "test" depends on action "code", so current_action() will
return "code" while that dependency is being executed.  Once that
action has completed, current_action() will again return "test".

If you need to know the name of the original action invoked by the
user, see L</invoked_action()> below.

=item depends_on(@actions)

[version 0.28]

Invokes the named action or list of actions in sequence.  Using this
method is preferred to calling the action explicitly because it
performs some internal record-keeping, and it ensures that the same
action is not invoked multiple times (note: in future versions of
Module::Build it's conceivable that this run-only-once mechanism will
be changed to something more intelligent).

Note that the name of this method is something of a misnomer; it
should really be called something like
C<invoke_actions_unless_already_invoked()> or something, but for
better or worse (perhaps better!) we were still thinking in
C<make>-like dependency terms when we created this method.

See also L<dispatch()|/"dispatch($action, %args)">.  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 dir_contains($first_dir, $second_dir)

[version 0.28]

Returns true if the first directory logically contains the second
directory.  This is just a convenience function because C<File::Spec>
doesn't really provide an easy way to figure this out (but
C<Path::Class> does...).

=item dispatch($action, %args)

[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

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

The multiple argument form allows you to set the paths for element types.
C<$value> must be a relative path using Unix-like paths.  (A series of
directories separated by slashes, e.g. C<foo/bar>.)  The return value is a
localized path based on C<$value>.

Assigning the value C<undef> to an element causes it to be removed.

=item install_destination($type)

[version 0.28]

Returns the directory in which items of type C<$type> (e.g. C<lib>,
C<arch>, C<bin>, or anything else returned by the L</install_types()>
method) will be installed during the C<install> action.  Any settings
for C<install_path>, C<install_base>, and C<prefix> are taken into
account when determining the return value.

=item install_path()

=item install_path($type)

=item install_path($type => $path)

[version 0.28]

Set or retrieve paths for specific installable elements. This is
useful when you want to examine any explicit install paths specified
by the user on the command line, or if you want to set the install
path for a specific installable element based on another attribute
like C<install_base()>.

With no argument, it returns a reference to a hash containing all
elements and their respective values. This hash should not be modified
directly; use the multiple argument below form to change values.

The single argument form returns the value associated with the
element C<$type>.

The multiple argument form allows you to set the paths for element types.
The supplied C<$path> should be an absolute path to install elements
of C<$type>.  The return value is C<$path>.

Assigning the value C<undef> to an element causes it to be removed.

=item install_types()

[version 0.28]

Returns a list of installable types that this build knows about.
These types each correspond to the name of a directory in F<blib/>,
and the list usually includes items such as C<lib>, C<arch>, C<bin>,
C<script>, C<libdoc>, C<bindoc>, and if HTML documentation is to be
built, C<libhtml> and C<binhtml>.  Other user-defined types may also
exist.

=item invoked_action()

[version 0.28]

This is the name of the original action invoked by the user.  This
value is set when the user invokes F<Build.PL>, the F<Build> script,
or programmatically through the L<dispatch()|/"dispatch($action, %args)">
method.  It does not change as sub-actions are executed as
dependencies are evaluated.

To get the name of the currently executing dependency, see
L</current_action()> above.

=item notes()

=item notes($key)

=item notes($key => $value)

[version 0.20]

The C<notes()> value allows you to store your own persistent
information about the build, and to share that information among
different entities involved in the build.  See the example in the
C<current()> method.

The C<notes()> method is essentially a glorified hash access.  With no
arguments, C<notes()> returns the entire hash of notes.  With one argument,
C<notes($key)> returns the value associated with the given key.  With two
arguments, C<notes($key, $value)> sets the value associated with the given key
to C<$value> and returns the new value.

The lifetime of the C<notes> data is for "a build" - that is, the
C<notes> hash is created when C<perl Build.PL> is run (or when the
C<new()> method is run, if the Module::Build Perl API is being used
instead of called from a shell), and lasts until C<perl Build.PL> is
run again or the C<clean> action is run.

=item orig_dir()

[version 0.28]

Returns a string containing the working directory that was in effect
before the F<Build> script chdir()-ed into the C<base_dir>.  This
might be useful for writing wrapper tools that might need to chdir()
back out.

=item os_type()

[version 0.04]

If you're subclassing Module::Build and some code needs to alter its
behavior based on the current platform, you may only need to know
whether you're running on Windows, Unix, MacOS, VMS, etc., and not the
fine-grained value of Perl's C<$^O> variable.  The C<os_type()> method
will return a string like C<Windows>, C<Unix>, C<MacOS>, C<VMS>, or
whatever is appropriate.  If you're running on an unknown platform, it
will return C<undef> - there shouldn't be many unknown platforms
though.

=item is_vmsish()

=item is_windowsish()

=item is_unixish()