Acme-Sort-Sleep
view release on metacpan or search on metacpan
local/lib/perl5/Module/Build/API.pod view on Meta::CPAN
/([\$*])(([\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 extra_manify_args
[version 0.4006]
Any extra arguments to pass to C<< Pod::Man->new() >> when building
man pages. One common choice might be C<< utf8 => 1 >> to get Unicode
support.
=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 => '+' },
}
);
( run in 1.505 second using v1.01-cache-2.11-cpan-39bf76dae61 )