Codex

Module::Build::Authoring

Section: User Contributed Perl Documentation (3pm)

Updated: 2014-09-19

Index?action=index Return to Main Contents


NAME

Module::Build::Authoring - Authoring Module::Build modules

DESCRIPTION

When creating a script for a module, something like the following code will typically be used:
A simple module could get away with something as short as this for its script:
The model used by is a lot like the metaphor, with the following correspondences:
Any customization can be done simply by subclassing and adding a method called (for example) , overriding the default 'test' action. You could also add a method called , and then you could perform the action .
For information on providing compatibility with , see Module::Build::Compat and <http://www.makemaker.org/wiki/index.cgi?ModuleBuildConversionGuide>.

STRUCTURE

Module::Build creates a class hierarchy conducive to customization. Here is the parent-child class hierarchy in classy ASCII art:

SUBCLASSING

Right now, there are two ways to subclass Module::Build. The first way is to create a regular module (in a file) that inherits from Module::Build, and use that module's class instead of using Module::Build directly:

------ in Build.PL: ---------- #!/usr/bin/perl

use lib q(/nonstandard/library/path); use My::Builder; # Or whatever you want to call it

my $build = My::Builder->new ( module_name => 'Foo::Bar', # All the regular args... license => 'perl', dist_author => 'A N Other <[email protected]>', requires => { Carp => 0 } ); $build->create_build_script;

@]

This is relatively straightforward, and is the best way to do things if your My::Builder class contains lots of code. The method will ensure that the current value of (including the ) is propagated to the Build script, so that My::Builder can be found when running build actions. If you find that you need to into a different directories in your subclass methods or actions, be sure to always return to the original directory (available via the method) before returning control to the parent class. This is important to avoid data serialization problems.
For very small additions, Module::Build provides a method that lets you subclass Module::Build more conveniently, without creating a separate file for your module:

------ in Build.PL: ---------- #!/usr/bin/perl

use Module::Build; my $class = Module::Build->subclass ( class => 'My::Builder', code => q{ sub ACTION_foo { print "I'm fooing to death!\n"; } }, );

my $build = $class->new ( module_name => 'Foo::Bar', # All the regular args... license => 'perl', dist_author => 'A N Other <[email protected]>', requires => { Carp => 0 } ); $build->create_build_script;

@]

Behind the scenes, this actually does create a file, since the code you provide must persist after Build.PL is run if it is to be very useful.

See also the documentation for the ``subclass()'' in Module::Build::API method.

PREREQUISITES

Types of prerequisites

To specify what versions of other modules are used by this distribution, several types of prerequisites can be defined with the following parameters:

configure_requires
Items that must be installed before configuring this distribution (i.e. before running the Build.PL script). This might be a specific minimum version of or any other module the Build.PL needs in order to do its stuff. Clients like or will be expected to pick out of the META.yml file and install these items before running the .

If no configure_requires is specified, the current version of Module::Build is automatically added to configure_requires.

:

build_requires
Items that are necessary for building and testing this distribution, but aren't necessary after installation. This can help users who only want to install these items temporarily. It also helps reduce the size of the CPAN dependency graph if everything isn't smooshed into .:
requires
Items that are necessary for basic functioning.:
recommends
Items that are recommended for enhanced functionality, but there are ways to use this distribution without having them installed. You might also think of this as ``can use or ``is aware of or ``changes behavior in the presence of''.:
test_requires
Items that are necessary for testing.:
conflicts
Items that can cause problems with this distribution when installed. This is pretty rare.:

Format of prerequisites

The prerequisites are given in a hash reference, where the keys are the module names and the values are version specifiers:

The above four version specifiers have different effects. The value means that at least version 2.4 of must be installed. The value means that any version of is acceptable, even if doesn't define a version. The more verbose value means that 's version must be at least 1.2, less than 2.0, and not equal to 1.5. The list of criteria is separated by commas, and all criteria must be satisfied.
A special entry lets you specify the versions of the Perl interpreter that are supported by your module. The same version dependency-checking semantics are available, except that we also understand perl's new double-dotted version numbers.

XS Extensions

Modules which need to compile XS code should list as a element.

SAVING CONFIGURATION INFORMATION

Module::Build provides a very convenient way to save configuration information that your installed modules (or your regression tests) can access. If your Build process calls the or methods, then a module will automatically be created for you, where is the parameter as passed to . This module provides access to the data saved by these methods, and a way to update the values. There is also a utility script called distributed with Module::Build that provides a command line interface to this same functionality. See also the generated documentation, and the script's documentation, for more information.

STARTING MODULE DEVELOPMENT

When starting development on a new module, it's rarely worth your time to create a tree of all the files by hand. Some automatic module-creators are available: the oldest is , which has shipped with perl itself for a long time. Its name reflects the fact that modules were originally conceived of as a way to wrap up a C library (thus the part) into perl extensions (thus the part).
These days, has largely been superseded by modules like , and . They have varying degrees of support for .

AUTOMATION

One advantage of Module::Build is that since it's implemented as Perl methods, you can invoke these methods directly if you want to install a module non-interactively. For instance, the following Perl script will invoke the entire build/install procedure:

If any of these steps encounters an error, it will throw a fatal exception.

You can also pass arguments as part of the build process:

Building and installing modules in this way skips creating the script.

MIGRATION

Note that if you want to provide both a Makefile.PL and a Build.PL for your distribution, you probably want to add the following to in your Makefile.PL so that doesn't try to run your Build.PL as a normal .PL file:
You may also be interested in looking at the module, which can automatically create various kinds of Makefile.PL compatibility layers.

AUTHOR

Ken Williams <[email protected]>

Development questions, bug reports, and patches should be sent to the Module-Build mailing list at <[email protected]>.

Bug reports are also welcome at <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build>.

The latest development version is available from the Git repository at <https://github.com/Perl-Toolchain-Gang/Module-Build>

SEE ALSO

perl?(1), Module::Build?(3), Module::Build::API?(3), Module::Build::Cookbook?(3), ExtUtils::MakeMaker?(3), YAML?(3)

META.yml Specification: CPAN::Meta::Spec

<http://www.dsmit.com/cons/>

<http://search.cpan.org/dist/PerlBuildSystem/>


Index

NAME

DESCRIPTION

STRUCTURE

SUBCLASSING

PREREQUISITES

Types of prerequisites

Format of prerequisites

XS Extensions

SAVING CONFIGURATION INFORMATION

STARTING MODULE DEVELOPMENT

AUTOMATION

MIGRATION

AUTHOR

SEE ALSO