App-Tel
view release on metacpan or search on metacpan
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
=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
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]
( run in 0.524 second using v1.01-cache-2.11-cpan-39bf76dae61 )