package Module::Build::Cookbook; =head1 NAME Module::Build::Cookbook - Examples of Module::Build Usage =head1 DESCRIPTION C isn't conceptually very complicated, but examples are always helpful. The following recipes should help developers and/or installers put together the pieces from the other parts of the documentation. =head1 BASIC RECIPES =head2 Installing modules that use Module::Build In most cases, you can just issue the following commands: perl Build.PL ./Build ./Build test ./Build install There's nothing complicated here - first you're running a script called F, then you're running a (newly-generated) script called F and passing it various arguments. The exact commands may vary a bit depending on how you invoke perl scripts on your system. For instance, if you have multiple versions of perl installed, you can install to one particular perl's library directories like so: /usr/bin/perl5.8.1 Build.PL ./Build ./Build test ./Build install If you're on Windows where the current directory is always searched first for scripts, you'll probably do something like this: perl Build.PL Build Build test Build install On the old Mac OS (version 9 or lower) using MacPerl, you can double-click on the F script to create the F script, then double-click on the F script to run its C, C, and C actions. The F script knows what perl was used to run F, so you don't need to re-invoke the F script with the complete perl path each time. If you invoke it with the I perl path, you'll get a warning or a fatal error. =head2 Modifying Config.pm values C relies heavily on various values from perl's C to do its work. For example, default installation paths are given by C and C and friends, C linker & compiler settings are given by C, C, C, C, and so on. I, you can tell C to pretend there are different values in F than what's really there, by passing arguments for the C<--config> parameter on the command line: perl Build.PL --config cc=gcc --config ld=gcc Inside the C script the same thing can be accomplished by passing values for the C parameter to C: my $build = Module::Build->new ( ... config => { cc => 'gcc', ld => 'gcc' }, ... ); In custom build code, the same thing can be accomplished by calling the L method: $build->config( cc => 'gcc' ); # Set $build->config( ld => 'gcc' ); # Set ... my $linker = $build->config('ld'); # Get =head2 Installing modules using the programmatic interface If you need to build, test, and/or install modules from within some other perl code (as opposed to having the user type installation commands at the shell), you can use the programmatic interface. Create a Module::Build object (or an object of a custom Module::Build subclass) and then invoke its C method to run various actions. my $build = Module::Build->new ( module_name => 'Foo::Bar', license => 'perl', requires => { 'Some::Module' => '1.23' }, ); $build->dispatch('build'); $build->dispatch('test', verbose => 1); $build->dispatch('install'); The first argument to C is the name of the action, and any following arguments are named parameters. This is the interface we use to test Module::Build itself in the regression tests. =head2 Installing to a temporary directory To create packages for package managers like RedHat's C or Debian's C, you may need to install to a temporary directory first and then create the package from that temporary installation. To do this, specify the C parameter to the C action: ./Build install --destdir /tmp/my-package-1.003 This essentially just prepends all the installation paths with the F directory. =head2 Installing to a non-standard directory To install to a non-standard directory (for example, if you don't have permission to install in the system-wide directories), you can use the C or C parameters: ./Build install --install_base /foo/bar See L for a much more complete discussion of how installation paths are determined. =head2 Installing in the same location as ExtUtils::MakeMaker With the introduction of C<--prefix> in Module::Build 0.28 and C in ExtUtils::MakeMaker 6.31 its easy to get them both to install to the same locations. First, ensure you have at least version 0.28 of Module::Build installed and 6.31 of ExtUtils::MakeMaker. Prior versions have differing (and in some cases quite strange) installation behaviors. The following installation flags are equivalent between ExtUtils::MakeMaker and Module::Build. MakeMaker Module::Build PREFIX=... --prefix ... INSTALL_BASE=... --install_base ... DESTDIR=... --destdir ... LIB=... --install_path lib=... INSTALLDIRS=... --installdirs ... INSTALLDIRS=perl --installdirs core UNINST=... --uninst ... INC=... --extra_compiler_flags ... POLLUTE=1 --extra_compiler_flags -DPERL_POLLUTE For example, if you are currently installing MakeMaker modules with this command: perl Makefile.PL PREFIX=~ make test make install UNINST=1 You can install into the same location with Module::Build using this: perl Build.PL --prefix ~ ./Build test ./Build install --uninst 1 =head3 C vs C The behavior of C is complicated and depends on how your Perl is configured. The resulting installation locations will vary from machine to machine and even different installations of Perl on the same machine. Because of this, it's difficult to document where C will place your modules. In contrast, C has predictable, easy to explain installation locations. Now that Module::Build and MakeMaker both have C there is little reason to use C other than to preserve your existing installation locations. If you are starting a fresh Perl installation we encourage you to use C. If you have an existing installation installed via C, consider moving it to an installation structure matching C and using that instead. =head2 Running a single test file C supports running a single test, which enables you to track down errors more quickly. Use the following format: ./Build test --test_files t/mytest.t In addition, you may want to run the test in verbose mode to get more informative output: ./Build test --test_files t/mytest.t --verbose 1 I run this so frequently that I define the following shell alias: alias t './Build test --verbose 1 --test_files' So then I can just execute C to run a single test. =head1 ADVANCED RECIPES =head2 Making a CPAN.pm-compatible distribution New versions of CPAN.pm understand how to use a F script, but old versions don't. If authors want to help users who have old versions, some form of F should be supplied. The easiest way to accomplish this is to use the C parameter to C<< Module::Build->new() >> in the C script, which can create various flavors of F during the C action. As a best practice, we recommend using the "traditional" style of F unless your distribution has needs that can't be accomplished that way. The C module, which is part of C's distribution, is responsible for creating these Fs. Please see L for the details. =head2 Changing the order of the build process The C property specifies the steps C will take when building a distribution. To change the build order, change the order of the entries in that property: # Process pod files first my @e = @{$build->build_elements}; my $i = grep {$e[$_] eq 'pod'} 0..$#e; unshift @e, splice @e, $i, 1; Currently, C has the following default value: [qw( PL support pm xs pod script )] Do take care when altering this property, since there may be non-obvious (and non-documented!) ordering dependencies in the C code. =head2 Adding new file types to the build process Sometimes you might have extra types of files that you want to install alongside the standard types like F<.pm> and F<.pod> files. For instance, you might have a F file containing some data related to the C module and you'd like for it to end up as F somewhere in perl's C<@INC> path so C can access it easily at runtime. The following code from a sample C file demonstrates how to accomplish this: use Module::Build; my $build = Module::Build->new ( module_name => 'Foo::Bar', ...other stuff here... ); $build->add_build_element('dat'); $build->create_build_script; This will find all F<.dat> files in the F directory, copy them to the F directory during the C action, and install them during the C action. If your extra files aren't located in the C directory in your distribution, you can explicitly say where they are, just as you'd do with F<.pm> or F<.pod> files: use Module::Build; my $build = new Module::Build ( module_name => 'Foo::Bar', dat_files => {'some/dir/Bar.dat' => 'lib/Foo/Bar.dat'}, ...other stuff here... ); $build->add_build_element('dat'); $build->create_build_script; If your extra files actually need to be created on the user's machine, or if they need some other kind of special processing, you'll probably want to subclass C and create a special method to process them, named C: use Module::Build; my $class = Module::Build->subclass(code => <<'EOF'); sub process_dat_files { my $self = shift; ... locate and process *.dat files, ... and create something in blib/lib/ } EOF my $build = $class->new ( module_name => 'Foo::Bar', ...other stuff here... ); $build->add_build_element('dat'); $build->create_build_script; If your extra files don't go in F but in some other place, see L<"Adding new elements to the install process"> for how to actually get them installed. Please note that these examples use some capabilities of Module::Build that first appeared in version 0.26. Before that it could still be done, but the simple cases took a bit more work. =head2 Adding new elements to the install process By default, Module::Build creates seven subdirectories of the F directory during the build process: F, F, F, F