3 Module::Build::Authoring - Authoring Module::Build modules
8 When creating a C<Build.PL> script for a module, something like the
9 following code will typically be used:
12 my $build = Module::Build->new
14 module_name => 'Foo::Bar',
18 'Some::Module' => '1.23',
19 'Other::Module' => '>= 1.2, != 1.5, < 2.0',
22 $build->create_build_script;
24 A simple module could get away with something as short as this for its
29 module_name => 'Foo::Bar',
31 )->create_build_script;
33 The model used by C<Module::Build> is a lot like the C<MakeMaker>
34 metaphor, with the following correspondences:
36 In Module::Build In ExtUtils::MakeMaker
37 --------------------------- ------------------------
38 Build.PL (initial script) Makefile.PL (initial script)
39 Build (a short perl script) Makefile (a long Makefile)
40 _build/ (saved state info) various config text in the Makefile
42 Any customization can be done simply by subclassing C<Module::Build>
43 and adding a method called (for example) C<ACTION_test>, overriding
44 the default 'test' action. You could also add a method called
45 C<ACTION_whatever>, and then you could perform the action C<Build
48 For information on providing compatibility with
49 C<ExtUtils::MakeMaker>, see L<Module::Build::Compat> and
50 L<http://www.makemaker.org/wiki/index.cgi?ModuleBuildConversionGuide>.
55 I list here some of the most important methods in C<Module::Build>.
56 Normally you won't need to deal with these methods unless you want to
57 subclass C<Module::Build>. But since one of the reasons I created
58 this module in the first place was so that subclassing is possible
59 (and easy), I will certainly write more docs as the interface
70 This method returns a reasonable facsimile of the currently-executing
71 C<Module::Build> object representing the current build. You can use
72 this object to query its C<notes()> method, inquire about installed
73 modules, and so on. This is a great way to share information between
74 different parts of your build process. For instance, you can ask
75 the user a question during C<perl Build.PL>, then use their answer
76 during a regression test:
79 my $color = $build->prompt("What is your favorite color?");
80 $build->notes(color => $color);
84 my $build = Module::Build->current;
85 my $color = $build->notes('color');
88 The way the C<current()> method is currently implemented, there may be
89 slight differences between the C<$build> object in Build.PL and the
90 one in C<t/colortest.t>. It is our goal to minimize these differences
91 in future releases of Module::Build, so please report any anomalies
94 One important caveat: in its current implementation, C<current()> will
95 B<NOT> work correctly if you have changed out of the directory that
96 C<Module::Build> was invoked from.
100 Creates a new Module::Build object. Arguments to the new() method are
101 listed below. Most arguments are optional, but you must provide
102 either the C<module_name> argument, or C<dist_name> and one of
103 C<dist_version> or C<dist_version_from>. In other words, you must
104 provide enough information to determine both a distribution name and
112 An array reference of files to be cleaned up when the C<clean> action
113 is performed. See also the add_to_cleanup() method.
117 This parameter supports the setting of features (see
118 L<feature($name)>) automatically based on a set of prerequisites. For
119 instance, for a module that could optionally use either MySQL or
120 PostgreSQL databases, you might use C<auto_features> like this:
122 my $build = Module::Build->new
124 ...other stuff here...
127 description => "Interface with Postgres databases",
128 requires => { 'DBD::Pg' => 23.3,
129 'DateTime::Format::Pg' => 0 },
132 description => "Interface with MySQL databases",
133 requires => { 'DBD::mysql' => 17.9,
134 'DateTime::Format::MySQL' => 0 },
139 For each feature named, the required prerequisites will be checked, and
140 if there are no failures, the feature will be enabled (set to C<1>).
141 Otherwise the failures will be displayed to the user and the feature
142 will be disabled (set to C<0>).
144 See the documentation for L<requires> for the details of how
145 requirements can be specified.
149 An optional C<autosplit> argument specifies a file which should be run
150 through the C<Autosplit::autosplit()> function. If multiple files
151 should be split, the argument may be given as an array of the files to
154 In general I don't consider autosplitting a great idea, because it's
155 not always clear that autosplitting achieves its intended performance
156 benefits. It may even harm performance in environments like mod_perl,
157 where as much as possible of a module's code should be loaded during
162 The Module::Build class or subclass to use in the build
163 script. Defaults to "Module::Build" or the class name passed to or
164 created by a call to C<subclass()>. This property is useful if you're
165 writing a custom Module::Build subclass and have a bootstrapping
166 problem--that is, your subclass requires modules that may not be
167 installed when C<perl Build.PL> is executed, but you've listed in
168 C<build_requires> so that they should be available when C<./Build> is
173 Modules listed in this section are necessary to build and install the
174 given module, but are not necessary for regular usage of it. This is
175 actually an important distinction - it allows for tighter control over
176 the body of installed modules, and facilitates correct dependency
177 checking on binary/packaged distributions of the module.
179 See the documentation for L<"PREREQUISITES"> for the details of how
180 requirements can be specified.
184 An optional C<c_source> argument specifies a directory which contains
185 C source files that the rest of the build may depend on. Any C<.c>
186 files in the directory will be compiled to object files. The
187 directory will be added to the search path during the compilation and
188 linking phases of any C or XS files.
192 Modules listed in this section conflict in some serious way with the
193 given module. C<Module::Build> (or some higher-level tool) will
194 refuse to install the given module if the given module/version is also
197 See the documentation for L<"PREREQUISITES"> for the details of how
198 requirements can be specified.
200 =item create_makefile_pl
202 This parameter lets you use Module::Build::Compat during the
203 C<distdir> (or C<dist>) action to automatically create a Makefile.PL
204 for compatibility with ExtUtils::MakeMaker. The parameter's value
205 should be one of the styles named in the Module::Build::Compat
210 This parameter tells Module::Build to automatically create a F<README>
211 file at the top level of your distribution. Currently it will simply
212 use C<Pod::Text> (or C<Pod::Readme> if it's installed) on the file
213 indicated by C<dist_version_from> and put the result in the F<README>
214 file. This is by no means the only recommended style for writing a
215 README, but it seems to be one common one used on the CPAN.
217 If you generate a F<README> in this way, it's probably a good idea to
218 create a separate F<INSTALL> file if that information isn't in the
223 This should be a short description of the distribution. This is used
224 when generating metadata for F<META.yml> and PPD files. If it is not
225 given then C<Module::Build> looks in the POD of the module from which
226 it gets the distribution's version. It looks for the first line
227 matching C<$package\s-\s(.+)>, and uses the captured text as the
232 This should be something like "John Doe <jdoe@example.com>", or if
233 there are multiple authors, an anonymous array of strings may be
234 specified. This is used when generating metadata for F<META.yml> and
235 PPD files. If this is not specified, then C<Module::Build> looks at
236 the module from which it gets the distribution's version. If it finds
237 a POD section marked "=head1 AUTHOR", then it uses the contents of
242 Specifies the name for this distribution. Most authors won't need to
243 set this directly, they can use C<module_name> to set C<dist_name> to
244 a reasonable default. However, some agglomerative distributions like
245 C<libwww-perl> or C<bioperl> have names that don't correspond directly
246 to a module name, so C<dist_name> can be set independently.
250 Specifies a version number for the distribution. See C<module_name>
251 or C<dist_version_from> for ways to have this set automatically from a
252 C<$VERSION> variable in a module. One way or another, a version
253 number needs to be set.
255 =item dist_version_from
257 Specifies a file to look for the distribution version in. Most
258 authors won't need to set this directly, they can use C<module_name>
259 to set it to a reasonable default.
261 The version is extracted from the specified file according to the same
262 rules as C<ExtUtils::MakeMaker> and C<CPAN.pm>. It involves finding
263 the first line that matches the regular expression
265 /([\$*])(([\w\:\']*)\bVERSION)\b.*\=/
267 eval()-ing that line, then checking the value of the C<$VERSION>
268 variable. Quite ugly, really, but all the modules on CPAN depend on
269 this process, so there's no real opportunity to change to something
274 A boolean flag indicating whether the F<Build.PL> file must be
275 executed, or whether this module can be built, tested and installed
276 solely from consulting its metadata file. The main reason to set this
277 to a true value is that your module performs some dynamic
278 configuration as part of its build/install process. If the flag is
279 omitted, the F<META.yml> spec says that installation tools should
280 treat it as 1 (true), because this is a safer way to behave.
282 Currently C<Module::Build> doesn't actually do anything with this flag
283 - it's up to higher-level tools like C<CPAN.pm> to do
284 something useful with it. It can potentially bring lots of security,
285 packaging, and convenience improvements.
287 =item extra_compiler_flags
289 =item extra_linker_flags
291 These parameters can contain array references (or strings, in which
292 case they will be split into arrays) to pass through to the compiler
293 and linker phases when compiling/linking C code. For example, to tell
294 the compiler that your code is C++, you might do:
296 my $build = Module::Build->new
298 module_name => 'Foo::Bar',
299 extra_compiler_flags => ['-x', 'c++'],
302 To link your XS code against glib you might write something like:
304 my $build = Module::Build->new
306 module_name => 'Foo::Bar',
308 extra_compiler_flags => scalar `glib-config --cflags`,
309 extra_linker_flags => scalar `glib-config --libs`,
314 You can pass arbitrary command line options to F<Build.PL> or
315 F<Build>, and they will be stored in the Module::Build object and can
316 be accessed via the C<args()> method. However, sometimes you want
317 more flexibility out of your argument processing than this allows. In
318 such cases, use the C<get_options> parameter to pass in a hash
319 reference of argument specifications, and the list of arguments to
320 F<Build.PL> or F<Build> will be processed according to those
321 specifications before they're passed on to C<Module::Build>'s own
324 The supported option specification hash keys are:
331 The type of option. The types are those supported by Getopt::Long; consult
332 its documentation for a complete list. Typical types are C<=s> for strings,
333 C<+> for additive options, and C<!> for negatable options. If the
334 type is not specified, it will be considered a boolean, i.e. no
335 argument is taken and a value of 1 will be assigned when the option is
340 A reference to a scalar in which to store the value passed to the option.
341 If not specified, the value will be stored under the option name in the
342 hash returned by the C<args()> method.
346 A default value for the option. If no default value is specified and no option
347 is passed, then the option key will not exist in the hash returned by
353 You can combine references to your own variables or subroutines with
354 unreferenced specifications, for which the result will also be stored in the
355 hash returned by C<args()>. For example:
358 my $build = Module::Build->new
360 module_name => 'Foo::Bar',
362 loud => { store => \$loud },
363 dbd => { type => '=s' },
364 quantity => { type => '+' },
368 print STDERR "HEY, ARE YOU LISTENING??\n" if $loud;
369 print "We'll use the ", $build->args('dbd'), " DBI driver\n";
370 print "Are you sure you want that many?\n"
371 if $build->args('quantity') > 2;
373 The arguments for such a specification can be called like so:
375 perl Build.PL --loud --dbd=DBD::pg --quantity --quantity --quantity
377 B<WARNING:> Any option specifications that conflict with Module::Build's own
378 options (defined by its properties) will throw an exception.
380 Consult the Getopt::Long documentation for details on its usage.
384 Specifies any additional directories in which to search for C header
385 files. May be given as a string indicating a single directory, or as
386 a list reference indicating multiple directories.
390 You can set paths for individual installable elements by using the
391 C<install_path> parameter:
393 my $build = Module::Build->new
395 ...other stuff here...
398 arch => '/foo/lib/arch',
404 Determines where files are installed within the normal perl hierarchy
405 as determined by F<Config.pm>. Valid values are: C<core>, C<site>,
406 C<vendor>. The default is C<site>. See
407 L<Module::Build/"INSTALL PATHS">
411 Specifies the licensing terms of your distribution. Valid options include:
418 The distribution is licensed under the Apache Software License
419 (http://opensource.org/licenses/apachepl.php).
423 The distribution is licensed under the Artistic License, as specified
424 by the F<Artistic> file in the standard perl distribution.
428 The distribution is licensed under the BSD License
429 (http://www.opensource.org/licenses/bsd-license.php).
433 The distribution is licensed under the terms of the Gnu General
434 Public License (http://www.opensource.org/licenses/gpl-license.php).
438 The distribution is licensed under the terms of the Gnu Lesser
439 General Public License
440 (http://www.opensource.org/licenses/lgpl-license.php).
444 The distribution is licensed under the MIT License
445 (http://opensource.org/licenses/mit-license.php).
449 The distribution is licensed under the Mozilla Public
450 License. (http://opensource.org/licenses/mozilla1.0.php or
451 http://opensource.org/licenses/mozilla1.1.php)
455 The distribution is licensed under some other Open Source
456 Initiative-approved license listed at
457 http://www.opensource.org/licenses/ .
461 The distribution may be copied and redistributed under the same terms
462 as perl itself (this is by far the most common licensing option for
463 modules on CPAN). This is a dual license, in which the user may
464 choose between either the GPL or the Artistic license.
468 The distribution may not be redistributed without special permission
469 from the author and/or copyright holder.
473 The distribution is licensed under a license that is B<not> approved
474 by www.opensource.org but that allows distribution without
480 Note that you must still include the terms of your license in your
481 documentation - this field only lets automated tools figure out your
482 licensing restrictions. Humans still need something to read. If you
483 choose to provide this field, you should make sure that you keep it in
484 sync with your written documentation if you ever change your licensing
487 It is a fatal error to use a license other than the ones mentioned
488 above. This is not because I wish to impose licensing terms on you -
489 please let me know if you would like another license option to be
490 added to the list. You may also use a license type of C<unknown> if
491 you don't wish to specify your terms (but this is usually not a good
492 idea for you to do!).
494 I just started out with a small set of licenses to keep things simple,
495 figuring I'd let people with actual working knowledge in this area
496 tell me what to do. So if that's you, drop me a line.
500 A hash of key/value pairs that should be added to the F<META.yml> file
501 during the C<distmeta> action. Any existing entries with the same
502 names will be overridden.
506 A hash of key/value pairs that should be merged into the F<META.yml>
507 file during the C<distmeta> action. Any existing entries with the
508 same names will be overridden.
510 The only difference between C<meta_add> and C<meta_merge> is their
511 behavior on hash-valued and array-valued entries: C<meta_add> will
512 completely blow away the existing hash or array value, but
513 C<meta_merge> will merge the supplied data into the existing hash or
518 The C<module_name> is a shortcut for setting default values of
519 C<dist_name> and C<dist_version_from>, reflecting the fact that the
520 majority of CPAN distributions are centered around one "main" module.
521 For instance, if you set C<module_name> to C<Foo::Bar>, then
522 C<dist_name> will default to C<Foo-Bar> and C<dist_version_from> will
523 default to C<lib/Foo/Bar.pm>. C<dist_version_from> will in turn be
524 used to set C<dist_version>.
526 Setting C<module_name> won't override a C<dist_*> parameter you
531 An optional parameter specifying a set of C<.PL> files in your
532 distribution. These will be run as Perl scripts prior to processing
533 the rest of the files in your distribution. They are usually used as
534 templates for creating other files dynamically, so that a file like
535 C<lib/Foo/Bar.pm.PL> might create the file C<lib/Foo/Bar.pm>.
537 The files are specified with the C<.PL> files as hash keys, and the
538 file(s) they generate as hash values, like so:
540 my $build = Module::Build->new
542 module_name => 'Foo::Bar',
544 PL_files => { 'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm' },
547 Note that the path specifications are I<always> given in Unix-like
548 format, not in the style of the local system.
550 If your C<.PL> scripts don't create any files, or if they create files
551 with unexpected names, or even if they create multiple files, you can
552 indicate that so that Module::Build can properly handle these created
556 'lib/Foo/Bar.pm.PL' => 'lib/Foo/Bar.pm',
557 'lib/something.PL' => ['/lib/something', '/lib/else'],
558 'lib/funny.PL' => [],
563 An optional parameter specifying the set of C<.pm> files in this
564 distribution, specified as a hash reference whose keys are the files'
565 locations in the distributions, and whose values are their logical
566 locations based on their package name, i.e. where they would be found
567 in a "normal" Module::Build-style distribution. This parameter is
568 mainly intended to support alternative layouts of files.
570 For instance, if you have an old-style MakeMaker distribution for a
571 module called C<Foo::Bar> and a F<Bar.pm> file at the top level of the
572 distribution, you could specify your layout in your C<Build.PL> like
575 my $build = Module::Build->new
577 module_name => 'Foo::Bar',
579 pm_files => { 'Bar.pm' => 'lib/Foo/Bar.pm' },
582 Note that the values should include C<lib/>, because this is where
583 they would be found in a "normal" Module::Build-style distribution.
585 Note also that the path specifications are I<always> given in
586 Unix-like format, not in the style of the local system.
590 Just like C<pm_files>, but used for specifying the set of C<.pod>
591 files in your distribution.
595 This is just like the C<requires> argument, except that modules listed
596 in this section aren't essential, just a good idea. We'll just print
597 a friendly warning if one of these modules aren't found, but we'll
600 If a module is recommended but not required, all tests should still
601 pass if the module isn't installed. This may mean that some tests
602 may be skipped if recommended dependencies aren't present.
604 Automated tools like CPAN.pm should inform the user when recommended
605 modules aren't installed, and it should offer to install them if it
608 See the documentation for L<"PREREQUISITES"> for the details of how
609 requirements can be specified.
613 An optional C<requires> argument specifies any module prerequisites
614 that the current module depends on.
616 One note: currently C<Module::Build> doesn't actually I<require> the
617 user to have dependencies installed, it just strongly urges. In the
618 future we may require it. There's also a C<recommends> section for
619 things that aren't absolutely required.
621 Automated tools like CPAN.pm should refuse to install a module if one
622 of its dependencies isn't satisfied, unless a "force" command is given
623 by the user. If the tools are helpful, they should also offer to
624 install the dependencies.
626 A synonym for C<requires> is C<prereq>, to help succour people
627 transitioning from C<ExtUtils::MakeMaker>. The C<requires> term is
628 preferred, but the C<prereq> term will remain valid in future
631 See the documentation for L<"PREREQUISITES"> for the details of how
632 requirements can be specified.
636 An optional parameter specifying a set of files that should be
637 installed as executable perl scripts when the module is installed.
638 May be given as an array reference of the files, or as a hash
639 reference whose keys are the files (and whose values will currently be
642 The default is to install no script files - in other words, there is
643 no default location where Module::Build will look for script files to
646 For backward compatibility, you may use the parameter C<scripts>
647 instead of C<script_files>. Please consider this usage deprecated,
648 though it will continue to exist for several version releases.
652 If a true value is specified for this parameter, C<Module::Signature>
653 will be used (via the 'distsign' action) to create a SIGNATURE file
654 for your distribution during the 'distdir' action, and to add the
655 SIGNATURE file to the MANIFEST (therefore, don't add it yourself).
657 The default value is false. In the future, the default may change to
658 true if you have C<Module::Signature> installed on your system.
662 An optional parameter specifying a set of files that should be used as
663 C<Test::Harness>-style regression tests to be run during the C<test>
664 action. May be given as an array reference of the files, or as a hash
665 reference whose keys are the files (and whose values will currently be
666 ignored). If the argument is given as a single string (not in an
667 array reference), that string will be treated as a C<glob()> pattern
668 specifying the files to use.
670 The default is to look for a F<test.pl> script in the top-level
671 directory of the distribution, and any files matching the glob pattern
672 C<*.t> in the F<t/> subdirectory. If the C<recursive_test_files>
673 property is true, then the C<t/> directory will be scanned recursively
678 Just like C<pm_files>, but used for specifying the set of C<.xs>
679 files in your distribution.
684 =item new_from_context(%args)
686 When called from a directory containing a F<Build.PL> script and a
687 F<META.yml> file (in other words, the base directory of a
688 distribution), this method will run the F<Build.PL> and return the
689 resulting C<Module::Build> object to the caller. Any key-value
690 arguments given to C<new_from_context()> are essentially like
691 command line arguments given to the F<Build.PL> script, so for example
692 you could pass C<< verbose => 1 >> to this method to turn on
697 You'll probably never call this method directly, it's only called from
698 the auto-generated C<Build> script. The C<new()> method is only
699 called once, when the user runs C<perl Build.PL>. Thereafter, when
700 the user runs C<Build test> or another action, the C<Module::Build>
701 object is created using the C<resume()> method to re-instantiate with
702 the settings given earlier to C<new()>.
706 This creates a new C<Module::Build> subclass on the fly, as described
707 in the L<"SUBCLASSING"> section. The caller must provide either a
708 C<class> or C<code> parameter, or both. The C<class> parameter
709 indicates the name to use for the new subclass, and defaults to
710 C<MyModuleBuilder>. The C<code> parameter specifies Perl code to use
711 as the body of the subclass.
721 =item add_build_element($type)
723 Adds a new type of entry to the build process. Accepts a single
724 string specifying its type-name. There must also be a method defined
725 to process things of that type, e.g. if you add a build element called
726 C<'foo'>, then you must also define a method called
727 C<process_foo_files()>.
729 See also L<Module::Build::Cookbook/"Adding new file types to the build process">.
731 =item add_to_cleanup(@files)
733 You may call C<< $self->add_to_cleanup(@patterns) >> to tell
734 C<Module::Build> that certain files should be removed when the user
735 performs the C<Build clean> action. The arguments to the method are
736 patterns suitable for passing to Perl's C<glob()> function, specified
737 in either Unix format or the current machine's native format. It's
738 usually convenient to use Unix format when you hard-code the filenames
739 (e.g. in F<Build.PL>) and the native format when the names are
740 programmatically generated (e.g. in a testing script).
742 I decided to provide a dynamic method of the C<$build> object, rather
743 than just use a static list of files named in the F<Build.PL>, because
744 these static lists can get difficult to manage. I usually prefer to
745 keep the responsibility for registering temporary files close to the
746 code that creates them.
750 my $args_href = $build->args;
751 my %args = $build->args;
752 my $arg_value = $build->args($key);
753 $build->args($key, $value);
755 This method is the preferred interface for retrieving the arguments passed via
756 command line options to F<Build.PL> or F<Build>, minus the Module-Build
759 When called in in a scalar context with no arguments, this method returns a
760 reference to the hash storing all of the arguments; in an array context, it
761 returns the hash itself. When passed a single argument, it returns the value
762 stored in the args hash for that option key. When called with two arguments,
763 the second argument is assigned to the args hash under the key passed as the
766 =item autosplit_file($from, $to)
768 Invokes the C<AutoSplit> module on the C<$from> file, sending the
769 output to the C<lib/auto> directory inside C<$to>. C<$to> is
770 typically the C<blib/> directory.
774 Returns a string containing the root-level directory of this build,
775 i.e. where the C<Build.PL> script and the C<lib> directory can be
776 found. This is usually the same as the current working directory,
777 because the C<Build> script will C<chdir()> into this directory as
778 soon as it begins execution.
780 =item build_requires()
782 Returns a hash reference indicating the C<build_requires>
783 prerequisites that were passed to the C<new()> method.
785 =item check_installed_status($module, $version)
787 This method returns a hash reference indicating whether a version
788 dependency on a certain module is satisfied. The C<$module> argument
789 is given as a string like C<"Data::Dumper"> or C<"perl">, and the
790 C<$version> argument can take any of the forms described in L<requires>
791 above. This allows very fine-grained version checking.
793 The returned hash reference has the following structure:
796 ok => $whether_the_dependency_is_satisfied,
797 have => $version_already_installed,
798 need => $version_requested, # Same as incoming $version argument
799 message => $informative_error_message,
802 If no version of C<$module> is currently installed, the C<have> value
803 will be the string C<< "<none>" >>. Otherwise the C<have> value will
804 simply be the version of the installed module. Note that this means
805 that if C<$module> is installed but doesn't define a version number,
806 the C<have> value will be C<undef> - this is why we don't use C<undef>
807 for the case when C<$module> isn't installed at all.
809 This method may be called either as an object method
810 (C<< $build->check_installed_status($module, $version) >>)
812 (C<< Module::Build->check_installed_status($module, $version) >>).
814 =item check_installed_version($module, $version)
816 Like C<check_installed_status()>, but simply returns true or false
817 depending on whether module C<$module> satisfies the dependency
820 If the check succeeds, the return value is the actual version of
821 C<$module> installed on the system. This allows you to do the
824 my $installed = $build->check_installed_version('DBI', '1.15');
826 print "Congratulations, version $installed of DBI is installed.\n";
828 die "Sorry, you must install DBI.\n";
831 If the check fails, we return false and set C<$@> to an informative
834 If C<$version> is any non-true value (notably zero) and any version of
835 C<$module> is installed, we return true. In this case, if C<$module>
836 doesn't define a version, or if its version is zero, we return the
837 special value "0 but true", which is numerically zero, but logically
840 In general you might prefer to use C<check_installed_status> if you
841 need detailed information, or this method if you just need a yes/no
844 =item compare_versions($v1, $op, $v2)
846 Compares two module versions C<$v1> and C<$v2> using the operator
847 C<$op>, which should be one of Perl's numeric operators like C<!=> or
848 C<< >= >> or the like. We do at least a halfway-decent job of
849 handling versions that aren't strictly numeric, like C<0.27_02>, but
850 exotic stuff will likely cause problems.
852 In the future, the guts of this method might be replaced with a call
853 out to C<version.pm>.
857 Returns a hash reference containing the C<Config.pm> hash, including
858 any changes the author or user has specified. This is a reference to
859 the actual internal hash we use, so you probably shouldn't modify
862 =item config_data($name)
864 =item config_data($name => $value)
866 With a single argument, returns the value of the configuration
867 variable C<$name>. With two arguments, sets the given configuration
868 variable to the given value. The value may be any perl scalar that's
869 serializable with C<Data::Dumper>. For instance, if you write a
870 module that can use a MySQL or PostgreSQL back-end, you might create
871 configuration variables called C<mysql_connect> and
872 C<postgres_connect>, and set each to an array of connection parameters
873 for C<< DBI->connect() >>.
875 Configuration values set in this way using the Module::Build object
876 will be available for querying during the build/test process and after
877 installation via the generated C<...::ConfigData> module, as
878 C<< ...::ConfigData->config($name) >>.
880 The C<feature()> and C<config_data()> methods represent
881 Module::Build's main support for configuration of installed modules.
882 See also L<SAVING CONFIGURATION INFORMATION>.
886 Returns a hash reference indicating the C<conflicts> prerequisites
887 that were passed to the C<new()> method.
889 =item contains_pod($file)
891 [Deprecated] Please see L<Module::Build::ModuleInfo> instead.
893 Returns true if the given file appears to contain POD documentation.
894 Currently this checks whether the file has a line beginning with
895 '=pod', '=head', or '=item', but the exact semantics may change in the
898 =item copy_if_modified(%parameters)
900 Takes the file in the C<from> parameter and copies it to the file in
901 the C<to> parameter, or the directory in the C<to_dir> parameter, if
902 the file has changed since it was last copied (or if it doesn't exist
903 in the new location). By default the entire directory structure of
904 C<from> will be copied into C<to_dir>; an optional C<flatten>
905 parameter will copy into C<to_dir> without doing so.
907 Returns the path to the destination file, or C<undef> if nothing
910 Any directories that need to be created in order to perform the
911 copying will be automatically created.
913 =item create_build_script()
915 Creates an executable script called C<Build> in the current directory
916 that will be used to execute further user actions. This script is
917 roughly analogous (in function, not in form) to the Makefile created
918 by C<ExtUtils::MakeMaker>. This method also creates some temporary
919 data in a directory called C<_build/>. Both of these will be removed
920 when the C<realclean> action is performed.
922 =item current_action()
924 Returns the name of the currently-running action, such as "build" or
925 "test". This action is not necessarily the action that was originally
926 invoked by the user. For example, if the user invoked the "test"
927 action, current_action() would initially return "test". However,
928 action "test" depends on action "code", so current_action() will
929 return "code" while that dependency is being executed. Once that
930 action has completed, current_action() will again return "test".
932 If you need to know the name of the original action invoked by the
933 user, see L<invoked_action()> below.
935 =item depends_on(@actions)
937 Invokes the named action or list of actions in sequence. Using this
938 method is preferred to calling the action explicitly because it
939 performs some internal record-keeping, and it ensures that the same
940 action is not invoked multiple times (note: in future versions of
941 Module::Build it's conceivable that this run-only-once mechanism will
942 be changed to something more intelligent).
944 Note that the name of this method is something of a misnomer; it
945 should really be called something like
946 C<invoke_actions_unless_already_invoked()> or something, but for
947 better or worse (perhaps better!) we were still thinking in
948 C<make>-like dependency terms when we created this method.
950 See also C<dispatch()>. The main distinction between the two is that
951 C<depends_on()> is meant to call an action from inside another action,
952 whereas C<dispatch()> is meant to set the very top action in motion.
954 =item dir_contains($first_dir, $second_dir)
956 Returns true if the first directory logically contains the second
957 directory. This is just a convenience function because C<File::Spec>
958 doesn't really provide an easy way to figure this out (but
959 C<Path::Class> does...).
961 =item dispatch($action, %args)
963 Invokes the build action C<$action>. Optionally, a list of options
964 and their values can be passed in. This is equivalent to invoking an
965 action at the command line, passing in a list of options.
967 Custom options that have not been registered must be passed in as a
968 hash reference in a key named "args":
970 $build->dispatch('foo', verbose => 1, args => { my_option => 'value' });
972 This method is intended to be used to programmatically invoke build
973 actions, e.g. by applications controlling Module::Build-based builds
974 rather than by subclasses.
976 See also C<depends_on()>. The main distinction between the two is that
977 C<depends_on()> is meant to call an action from inside another action,
978 whereas C<dispatch()> is meant to set the very top action in motion.
982 Returns the name of the directory that will be created during the
983 C<dist> action. The name is derived from the C<dist_name> and
984 C<dist_version> properties.
988 Returns the name of the current distribution, as passed to the
989 C<new()> method in a C<dist_name> or modified C<module_name>
994 Returns the version of the current distribution, as determined by the
995 C<new()> method from a C<dist_version>, C<dist_version_from>, or
996 C<module_name> parameter.
998 =item do_system($cmd, @args)
1000 This is a fairly simple wrapper around Perl's C<system()> built-in
1001 command. Given a command and an array of optional arguments, this
1002 method will print the command to C<STDOUT>, and then execute it using
1003 Perl's C<system()>. It returns true or false to indicate success or
1004 failure (the opposite of how C<system()> works, but more intuitive).
1006 Note that if you supply a single argument to C<do_system()>, it
1007 will/may be processed by the systems's shell, and any special
1008 characters will do their special things. If you supply multiple
1009 arguments, no shell will get involved and the command will be executed
1012 =item feature($name)
1014 =item feature($name => $value)
1016 With a single argument, returns true if the given feature is set.
1017 With two arguments, sets the given feature to the given boolean value.
1018 In this context, a "feature" is any optional functionality of an
1019 installed module. For instance, if you write a module that could
1020 optionally support a MySQL or PostgreSQL backend, you might create
1021 features called C<mysql_support> and C<postgres_support>, and set them
1022 to true/false depending on whether the user has the proper databases
1023 installed and configured.
1025 Features set in this way using the Module::Build object will be
1026 available for querying during the build/test process and after
1027 installation via the generated C<...::ConfigData> module, as
1028 C<< ...::ConfigData->feature($name) >>.
1030 The C<feature()> and C<config_data()> methods represent
1031 Module::Build's main support for configuration of installed modules.
1032 See also L<SAVING CONFIGURATION INFORMATION>.
1034 =item have_c_compiler()
1036 Returns true if the current system seems to have a working C compiler.
1037 We currently determine this by attempting to compile a simple C source
1038 file and reporting whether the attempt was successful.
1040 =item install_destination($type)
1042 Returns the directory in which items of type C<$type> (e.g. C<lib>,
1043 C<arch>, C<bin>, or anything else returned by the C<install_types()>
1044 method) will be installed during the C<install> action. Any settings
1045 for C<install_path>, C<install_base>, and C<prefix> are taken into
1046 account when determining the return value.
1048 =item install_types()
1050 Returns a list of installable types that this build knows about.
1051 These types each correspond to the name of a directory in F<blib/>,
1052 and the list usually includes items such as C<lib>, C<arch>, C<bin>,
1053 C<script>, C<libdoc>, C<bindoc>, and if HTML documentation is to be
1054 built, C<libhtml> and C<binhtml>. Other user-defined types may also
1057 =item invoked_action()
1059 This is the name of the original action invoked by the user. This
1060 value is set when the user invokes F<Build.PL>, the F<Build> script,
1061 or programatically through the L<dispatch()> method. It does not
1062 change as sub-actions are executed as dependencies are evaluated.
1064 To get the name of the currently executing dependency, see
1065 L<current_action()> above.
1071 =item notes($key => $value)
1073 The C<notes()> value allows you to store your own persistent
1074 information about the build, and to share that information among
1075 different entities involved in the build. See the example in the
1076 C<current()> method.
1078 The C<notes()> method is essentally a glorified hash access. With no
1079 arguments, C<notes()> returns the entire hash of notes. With one argument,
1080 C<notes($key)> returns the value associated with the given key. With two
1081 arguments, C<notes($key, $value)> sets the value associated with the given key
1082 to C<$value> and returns the new value.
1084 The lifetime of the C<notes> data is for "a build" - that is, the
1085 C<notes> hash is created when C<perl Build.PL> is run (or when the
1086 C<new()> method is run, if the Module::Build Perl API is being used
1087 instead of called from a shell), and lasts until C<perl Build.PL> is
1088 run again or the C<clean> action is run.
1092 Returns a string containing the working directory that was in effect
1093 before the F<Build> script chdir()-ed into the C<base_dir>. This
1094 might be useful for writing wrapper tools that might need to chdir()
1097 =item rscan_dir($dir, $pattern)
1099 Uses C<File::Find> to traverse the directory C<$dir>, returning a
1100 reference to an array of entries matching C<$pattern>. C<$pattern>
1101 may either be a regular expression (using C<qr//> or just a plain
1102 string), or a reference to a subroutine that will return true for
1103 wanted entries. If C<$pattern> is not given, all entries will be
1108 # All the *.pm files in lib/
1109 $m->rscan_dir('lib', qr/\.pm$/)
1111 # All the files in blib/ that aren't *.html files
1112 $m->rscan_dir('blib', sub {-f $_ and not /\.html$/});
1114 # All the files in t/
1117 =item runtime_params()
1119 =item runtime_params($key)
1121 The C<runtime_params()> method stores the values passed on the command line
1122 for valid properties (that is, any command line options for which
1123 C<valid_property()> returns a true value). The value on the command line may
1124 override the default value for a property, as well as any value specified in a
1125 call to C<new()>. This allows you to programmatically tell if C<perl Build.PL>
1126 or any execution of C<./Build> had command line options specified that
1127 override valid properties.
1129 The C<runtime_params()> method is essentally a glorified read-only hash. With
1130 no arguments, C<runtime_params()> returns the entire hash of properties
1131 specified on the command line. With one argument, C<runtime_params($key)>
1132 returns the value associated with the given key.
1134 The lifetime of the C<runtime_params> data is for "a build" - that is, the
1135 C<runtime_params> hash is created when C<perl Build.PL> is run (or when the
1136 C<new()> method is called, if the Module::Build Perl API is being used instead
1137 of called from a shell), and lasts until C<perl Build.PL> is run again or the
1138 C<clean> action is run.
1142 If you're subclassing Module::Build and some code needs to alter its
1143 behavior based on the current platform, you may only need to know
1144 whether you're running on Windows, Unix, MacOS, VMS, etc., and not the
1145 fine-grained value of Perl's C<$^O> variable. The C<os_type()> method
1146 will return a string like C<Windows>, C<Unix>, C<MacOS>, C<VMS>, or
1147 whatever is appropriate. If you're running on an unknown platform, it
1148 will return C<undef> - there shouldn't be many unknown platforms
1151 =item prepare_metadata()
1153 This method is provided for authors to override to customize the
1154 fields of F<META.yml>. It is passed a YAML::Node node object which can
1155 be modified as desired and then returned. E.g.
1157 package My::Builder;
1158 use base 'Module::Build';
1160 sub prepare_metadata {
1162 my $node = $self->SUPER::prepare_metadata( shift );
1163 $node->{custom_field} = 'foo';
1167 =item prereq_failures()
1169 Returns a data structure containing information about any failed
1170 prerequisites (of any of the types described above), or C<undef> if
1171 all prerequisites are met.
1173 The data structure returned is a hash reference. The top level keys
1174 are the type of prerequisite failed, one of "requires",
1175 "build_requires", "conflicts", or "recommends". The associated values
1176 are hash references whose keys are the names of required (or
1177 conflicting) modules. The associated values of those are hash
1178 references indicating some information about the failure. For example:
1183 message => 'Version 0.42 is installed, but we need version 0.59',
1191 message => 'Prerequisite Foo isn't installed',
1194 This hash has the same structure as the hash returned by the
1195 C<check_installed_status()> method, except that in the case of
1196 "conflicts" dependencies we change the "need" key to "conflicts" and
1197 construct a proper message.
1201 # Check a required dependency on Foo::Bar
1202 if ( $build->prereq_failures->{requires}{Foo::Bar} ) { ...
1204 # Check whether there were any failures
1205 if ( $build->prereq_failures ) { ...
1207 # Show messages for all failures
1208 my $failures = $build->prereq_failures;
1209 while (my ($type, $list) = each %$failures) {
1210 while (my ($name, $hash) = each %$list) {
1211 print "Failure for $name: $hash->{message}\n";
1215 =item prereq_report()
1217 Returns a human-readable (table-form) string showing all
1218 prerequisites, the versions required, and the versions actually
1219 installed. This can be useful for reviewing the configuration of your
1220 system prior to a build, or when compiling data to send for a bug
1221 report. The C<prereq_report> action is just a thin wrapper around the
1222 C<prereq_report()> method.
1224 =item prompt($message, $default)
1226 Asks the user a question and returns their response as a string. The
1227 first argument specifies the message to display to the user (for
1228 example, C<"Where do you keep your money?">). The second argument,
1229 which is optional, specifies a default answer (for example,
1230 C<"wallet">). The user will be asked the question once.
1232 If C<prompt()> detects that it is not running interactively and there
1233 is nothing on STDIN or if the PERL_MM_USE_DEFAULT environment variable
1234 is set to true, the $default will be used without prompting. This
1235 prevents automated processes from blocking on user input.
1237 If no $default is provided an empty string will be used instead.
1239 This method may be called as a class or object method.
1243 Returns a hash reference indicating the C<recommends> prerequisites
1244 that were passed to the C<new()> method.
1248 Returns a hash reference indicating the C<requires> prerequisites that
1249 were passed to the C<new()> method.
1251 =item script_files()
1253 Returns a hash reference whose keys are the perl script files to be
1254 installed, if any. This corresponds to the C<script_files> parameter to the
1255 C<new()> method. With an optional argument, this parameter may be set
1258 For backward compatibility, the C<scripts()> method does exactly the
1259 same thing as C<script_files()>. C<scripts()> is deprecated, but it
1260 will stay around for several versions to give people time to
1263 =item up_to_date($source_file, $derived_file)
1265 =item up_to_date(\@source_files, \@derived_files)
1267 This method can be used to compare a set of source files to a set of
1268 derived files. If any of the source files are newer than any of the
1269 derived files, it returns false. Additionally, if any of the derived
1270 files do not exist, it returns false. Otherwise it returns true.
1272 The arguments may be either a scalar or an array reference of file
1275 =item y_n($message, $default)
1277 Asks the user a yes/no question using C<prompt()> and returns true or
1278 false accordingly. The user will be asked the question repeatedly
1279 until they give an answer that looks like "yes" or "no".
1281 The first argument specifies the message to display to the user (for
1282 example, C<"Shall I invest your money for you?">), and the second
1283 argument specifies the default answer (for example, C<"y">).
1285 Note that the default is specified as a string like C<"y"> or C<"n">,
1286 and the return value is a Perl boolean value like 1 or 0. I thought
1287 about this for a while and this seemed like the most useful way to do
1290 This method may be called as a class or object method.
1295 =head2 Autogenerated Accessors
1297 In addition to the aforementioned methods, there are also some get/set
1298 accessor methods for the following properties:
1316 =item build_elements()
1318 =item build_requires()
1320 =item build_script()
1330 =item create_makefile_pl()
1332 =item create_readme()
1342 =item include_dirs()
1344 =item install_base()
1346 =item install_path()
1348 =item install_sets()
1356 =item magic_number()
1370 =item original_prefix()
1382 =item prereq_action_types()
1388 =item recurse_into()
1390 =item recursive_test_files()
1405 =head1 PREREQUISITES
1407 There are three basic types of prerequisites that can be defined: 1)
1408 "requires" - are versions of modules that are required for certain
1409 functionality to be available; 2) "recommends" - are versions of
1410 modules that are recommended to provide enhanced functionality; and 3)
1411 "conflicts" - are versions of modules that conflict with, and that can
1412 cause problems with the distribution.
1414 Each of the three types of prerequisites listed above can be applied
1415 to different aspects of the Build process. For the module distribution
1416 itself you simply define "requires", "recommends", or "conflicts". The
1417 types can also apply to other aspects of the Build process. Currently,
1418 only "build_requires" is defined which is used for modules which are
1419 required during the Build process.
1422 =head2 Format of prerequisites
1424 The prerequisites are given in a hash reference, where the keys are
1425 the module names and the values are version specifiers:
1428 Foo::Module => '2.4',
1430 Ken::Module => '>= 1.2, != 1.5, < 2.0',
1434 These four version specifiers have different effects. The value
1435 C<'2.4'> means that B<at least> version 2.4 of C<Foo::Module> must be
1436 installed. The value C<0> means that B<any> version of C<Bar::Module>
1437 is acceptable, even if C<Bar::Module> doesn't define a version. The
1438 more verbose value C<'E<gt>= 1.2, != 1.5, E<lt> 2.0'> means that
1439 C<Ken::Module>'s version must be B<at least> 1.2, B<less than> 2.0,
1440 and B<not equal to> 1.5. The list of criteria is separated by commas,
1441 and all criteria must be satisfied.
1443 A special C<perl> entry lets you specify the versions of the Perl
1444 interpreter that are supported by your module. The same version
1445 dependency-checking semantics are available, except that we also
1446 understand perl's new double-dotted version numbers.
1449 =head1 SAVING CONFIGURATION INFORMATION
1451 Module::Build provides a very convenient way to save configuration
1452 information that your installed modules (or your regression tests) can
1453 access. If your Build process calls the C<feature()> or
1454 C<config_data()> methods, then a C<Foo::Bar::ConfigData> module will
1455 automatically be created for you, where C<Foo::Bar> is the
1456 C<module_name> parameter as passed to C<new()>. This module provides
1457 access to the data saved by these methods, and a way to update the
1458 values. There is also a utility script called C<config_data>
1459 distributed with Module::Build that provides a command line interface
1460 to this same functionality. See also the generated
1461 C<Foo::Bar::ConfigData> documentation, and the C<config_data>
1462 script's documentation, for more information.
1467 One advantage of Module::Build is that since it's implemented as Perl
1468 methods, you can invoke these methods directly if you want to install
1469 a module non-interactively. For instance, the following Perl script
1470 will invoke the entire build/install procedure:
1472 my $build = Module::Build->new(module_name => 'MyModule');
1473 $build->dispatch('build');
1474 $build->dispatch('test');
1475 $build->dispatch('install');
1477 If any of these steps encounters an error, it will throw a fatal
1480 You can also pass arguments as part of the build process:
1482 my $build = Module::Build->new(module_name => 'MyModule');
1483 $build->dispatch('build');
1484 $build->dispatch('test', verbose => 1);
1485 $build->dispatch('install', sitelib => '/my/secret/place/');
1487 Building and installing modules in this way skips creating the
1493 Module::Build creates a class hierarchy conducive to customization.
1494 Here is the parent-child class hierarchy in classy ASCII art:
1496 /--------------------\
1497 | Your::Parent | (If you subclass Module::Build)
1498 \--------------------/
1501 /--------------------\ (Doesn't define any functionality
1502 | Module::Build | of its own - just figures out what
1503 \--------------------/ other modules to load.)
1506 /-----------------------------------\ (Some values of $^O may
1507 | Module::Build::Platform::$^O | define specialized functionality.
1508 \-----------------------------------/ Otherwise it's ...::Default, a
1509 | pass-through class.)
1511 /--------------------------\
1512 | Module::Build::Base | (Most of the functionality of
1513 \--------------------------/ Module::Build is defined here.)
1518 Right now, there are two ways to subclass Module::Build. The first
1519 way is to create a regular module (in a C<.pm> file) that inherits
1520 from Module::Build, and use that module's class instead of using
1521 Module::Build directly:
1523 ------ in Build.PL: ----------
1526 use lib q(/nonstandard/library/path);
1527 use My::Builder; # Or whatever you want to call it
1529 my $build = My::Builder->new
1531 module_name => 'Foo::Bar', # All the regular args...
1533 dist_author => 'A N Other <me@here.net.au>',
1534 requires => { Carp => 0 }
1536 $build->create_build_script;
1538 This is relatively straightforward, and is the best way to do things
1539 if your My::Builder class contains lots of code. The
1540 C<create_build_script()> method will ensure that the current value of
1541 C<@INC> (including the C</nonstandard/library/path>) is propogated to
1542 the Build script, so that My::Builder can be found when running build
1545 For very small additions, Module::Build provides a C<subclass()>
1546 method that lets you subclass Module::Build more conveniently, without
1547 creating a separate file for your module:
1549 ------ in Build.PL: ----------
1553 my $class = Module::Build->subclass
1555 class => 'My::Builder',
1558 print "I'm fooing to death!\n";
1563 my $build = $class->new
1565 module_name => 'Foo::Bar', # All the regular args...
1567 dist_author => 'A N Other <me@here.net.au>',
1568 requires => { Carp => 0 }
1570 $build->create_build_script;
1572 Behind the scenes, this actually does create a C<.pm> file, since the
1573 code you provide must persist after Build.PL is run if it is to be
1576 See also the documentation for the C<subclass()> method.
1579 =head1 STARTING MODULE DEVELOPMENT
1581 When starting development on a new module, it's rarely worth your time
1582 to create a tree of all the files by hand. Some automatic
1583 module-creators are available: the oldest is C<h2xs>, which has
1584 shipped with perl itself for a long time. Its name reflects the fact
1585 that modules were originally conceived of as a way to wrap up a C
1586 library (thus the C<h> part) into perl extensions (thus the C<xs>
1589 These days, C<h2xs> has largely been superseded by modules like
1590 C<ExtUtils::ModuleMaker>, C<Module::Starter>, and C<Module::Maker>.
1591 They have varying degrees of support for C<Module::Build>.
1596 Note that if you want to provide both a F<Makefile.PL> and a
1597 F<Build.PL> for your distribution, you probably want to add the
1598 following to C<WriteMakefile> in your F<Makefile.PL> so that MakeMaker
1599 doesn't try to run your F<Build.PL> as a normal F<.PL> file:
1603 You may also be interested in looking at the C<Module::Build::Compat>
1604 module, which can automatically create various kinds of F<Makefile.PL>
1605 compatibility layers.
1610 Ken Williams, kwilliams@cpan.org
1612 Development questions, bug reports, and patches should be sent to the
1613 Module-Build mailing list at module-build-general@lists.sourceforge.net .
1615 Bug reports are also welcome at
1616 http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Build .
1618 An anonymous CVS repository containing the latest development version
1619 is available; see http://sourceforge.net/cvs/?group_id=45731 for the
1620 details of how to access it.
1625 perl(1), Module::Build(3), Module::Build::Cookbook(3),
1626 ExtUtils::MakeMaker(3), YAML(3)
1628 F<META.yml> Specification:
1629 L<http://module-build.sourceforge.net/META-spec-v1.2.html>
1631 L<http://www.dsmit.com/cons/>