From b8851fcc53cbe24fd20b090f26dd149e353f6174 Mon Sep 17 00:00:00 2001 From: afresh1 Date: Sun, 5 Feb 2017 00:31:51 +0000 Subject: Fix merge issues, remove excess files - match perl-5.24.1 dist --- .../cpan/Module-Build/lib/Module/Build/Cookbook.pm | 529 --------------------- 1 file changed, 529 deletions(-) delete mode 100644 gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build/Cookbook.pm (limited to 'gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build/Cookbook.pm') diff --git a/gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build/Cookbook.pm b/gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build/Cookbook.pm deleted file mode 100644 index 08d10b3ceb2..00000000000 --- a/gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build/Cookbook.pm +++ /dev/null @@ -1,529 +0,0 @@ -package Module::Build::Cookbook; -use strict; -use vars qw($VERSION); -$VERSION = '0.4205'; - - -=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 C 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 C. Prior versions have -differing (and in some cases quite strange) installation behaviors. - -The following installation flags are equivalent between -C and C. - - 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 C 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 C and C 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