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 --- .../perl/cpan/Module-Build/lib/Module/Build.pm | 1117 -------------------- 1 file changed, 1117 deletions(-) delete mode 100644 gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build.pm (limited to 'gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build.pm') diff --git a/gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build.pm b/gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build.pm deleted file mode 100644 index aee7b44c1f5..00000000000 --- a/gnu/usr.bin/perl/cpan/Module-Build/lib/Module/Build.pm +++ /dev/null @@ -1,1117 +0,0 @@ -package Module::Build; - -use if $] >= 5.019, 'deprecate'; - -# This module doesn't do much of anything itself, it inherits from the -# modules that do the real work. The only real thing it has to do is -# figure out which OS-specific module to pull in. Many of the -# OS-specific modules don't do anything either - most of the work is -# done in Module::Build::Base. - -use strict; -use File::Spec (); -use File::Path (); -use File::Basename (); -use Perl::OSType (); - -use Module::Build::Base; - -use vars qw($VERSION @ISA); -@ISA = qw(Module::Build::Base); -$VERSION = '0.4205'; -$VERSION = eval $VERSION; - -# Inserts the given module into the @ISA hierarchy between -# Module::Build and its immediate parent -sub _interpose_module { - my ($self, $mod) = @_; - eval "use $mod"; - die $@ if $@; - - no strict 'refs'; - my $top_class = $mod; - while (@{"${top_class}::ISA"}) { - last if ${"${top_class}::ISA"}[0] eq $ISA[0]; - $top_class = ${"${top_class}::ISA"}[0]; - } - - @{"${top_class}::ISA"} = @ISA; - @ISA = ($mod); -} - -if (grep {-e File::Spec->catfile($_, qw(Module Build Platform), $^O) . '.pm'} @INC) { - __PACKAGE__->_interpose_module("Module::Build::Platform::$^O"); - -} elsif ( my $ostype = os_type() ) { - __PACKAGE__->_interpose_module("Module::Build::Platform::$ostype"); - -} else { - warn "Unknown OS type '$^O' - using default settings\n"; -} - -sub os_type { return Perl::OSType::os_type() } - -sub is_vmsish { return Perl::OSType::is_os_type('VMS') } -sub is_windowsish { return Perl::OSType::is_os_type('Windows') } -sub is_unixish { return Perl::OSType::is_os_type('Unix') } - -1; - -__END__ - -=for :stopwords -bindoc binhtml destdir distcheck distclean distdir distmeta distsign disttest -fakeinstall html installdirs installsitebin installsitescript installvendorbin -installvendorscript libdoc libhtml pardist ppd ppmdist realclean skipcheck -testall testcover testdb testpod testpodcoverage versioninstall - -=head1 NAME - -Module::Build - Build and install Perl modules - -=head1 SYNOPSIS - -Standard process for building & installing modules: - - perl Build.PL - ./Build - ./Build test - ./Build install - -Or, if you're on a platform (like DOS or Windows) that doesn't require -the "./" notation, you can do this: - - perl Build.PL - Build - Build test - Build install - - -=head1 DESCRIPTION - -C is a system for building, testing, and installing -Perl modules. It is meant to be an alternative to -C. Developers may alter the behavior of the -module through subclassing in a much more straightforward way than -with C. It also does not require a C on your system -- most of the C code is pure-perl and written in a very -cross-platform way. - -See L<"MOTIVATIONS"> for more comparisons between C -and C. - -To install C, and any other module that uses -C for its installation process, do the following: - - perl Build.PL # 'Build.PL' script creates the 'Build' script - ./Build # Need ./ to ensure we're using this "Build" script - ./Build test # and not another one that happens to be in the PATH - ./Build install - -This illustrates initial configuration and the running of three -'actions'. In this case the actions run are 'build' (the default -action), 'test', and 'install'. Other actions defined so far include: - - build manifest - clean manifest_skip - code manpages - config_data pardist - diff ppd - dist ppmdist - distcheck prereq_data - distclean prereq_report - distdir pure_install - distinstall realclean - distmeta retest - distsign skipcheck - disttest test - docs testall - fakeinstall testcover - help testdb - html testpod - install testpodcoverage - installdeps versioninstall - -You can run the 'help' action for a complete list of actions. - - -=head1 GUIDE TO DOCUMENTATION - -The documentation for C is broken up into sections: - -=over - -=item General Usage (L) - -This is the document you are currently reading. It describes basic -usage and background information. Its main purpose is to assist the -user who wants to learn how to invoke and control C -scripts at the command line. - -=item Authoring Reference (L) - -This document describes the structure and organization of -C, and the relevant concepts needed by authors who are -writing F scripts for a distribution or controlling -C processes programmatically. - -=item API Reference (L) - -This is a reference to the C API. - -=item Cookbook (L) - -This document demonstrates how to accomplish many common tasks. It -covers general command line usage and authoring of F -scripts. Includes working examples. - -=back - - -=head1 ACTIONS - -There are some general principles at work here. First, each task when -building a module is called an "action". These actions are listed -above; they correspond to the building, testing, installing, -packaging, etc., tasks. - -Second, arguments are processed in a very systematic way. Arguments -are always key=value pairs. They may be specified at C -time (i.e. C), in which case -their values last for the lifetime of the C script. They may -also be specified when executing a particular action (i.e. -C), in which case their values last only for the -lifetime of that command. Per-action command line parameters take -precedence over parameters specified at C time. - -The build process also relies heavily on the C module. -If the user wishes to override any of the -values in C, she may specify them like so: - - perl Build.PL --config cc=gcc --config ld=gcc - -The following build actions are provided by default. - -=over 4 - -=item build - -[version 0.01] - -If you run the C script without any arguments, it runs the -C action, which in turn runs the C and C actions. - -This is analogous to the C I target. - -=item clean - -[version 0.01] - -This action will clean up any files that the build process may have -created, including the C directory (but not including the -C<_build/> directory and the C script itself). - -=item code - -[version 0.20] - -This action builds your code base. - -By default it just creates a C directory and copies any C<.pm> -and C<.pod> files from your C directory into the C -directory. It also compiles any C<.xs> files from C and places -them in C. Of course, you need a working C compiler (probably -the same one that built perl itself) for the compilation to work -properly. - -The C action also runs any C<.PL> files in your F -directory. Typically these create other files, named the same but -without the C<.PL> ending. For example, a file F -could create the file F. The C<.PL> files are -processed first, so any C<.pm> files (or other kinds that we deal -with) will get copied correctly. - -=item config_data - -[version 0.26] - -... - -=item diff - -[version 0.14] - -This action will compare the files about to be installed with their -installed counterparts. For .pm and .pod files, a diff will be shown -(this currently requires a 'diff' program to be in your PATH). For -other files like compiled binary files, we simply report whether they -differ. - -A C parameter may be passed to the action, which will be passed -to the 'diff' program. Consult your 'diff' documentation for the -parameters it will accept - a good one is C<-u>: - - ./Build diff flags=-u - -=item dist - -[version 0.02] - -This action is helpful for module authors who want to package up their -module for source distribution through a medium like CPAN. It will create a -tarball of the files listed in F and compress the tarball using -GZIP compression. - -By default, this action will use the C module. However, you can -force it to use binary "tar" and "gzip" executables by supplying an explicit -C (and optional C) parameter: - - ./Build dist --tar C:\path\to\tar.exe --gzip C:\path\to\zip.exe - -=item distcheck - -[version 0.05] - -Reports which files are in the build directory but not in the -F file, and vice versa. (See L for details.) - -=item distclean - -[version 0.05] - -Performs the 'realclean' action and then the 'distcheck' action. - -=item distdir - -[version 0.05] - -Creates a "distribution directory" named C<$dist_name-$dist_version> -(if that directory already exists, it will be removed first), then -copies all the files listed in the F file to that directory. -This directory is what the distribution tarball is created from. - -=item distinstall - -[version 0.37] - -Performs the 'distdir' action, then switches into that directory and runs a -C, followed by the 'build' and 'install' actions in that -directory. Use PERL_MB_OPT or F<.modulebuildrc> to set options that should be -applied during subprocesses - -=item distmeta - -[version 0.21] - -Creates the F file that describes the distribution. - -F is a file containing various bits of I about the -distribution. The metadata includes the distribution name, version, -abstract, prerequisites, license, and various other data about the -distribution. This file is created as F in a simplified YAML format. - -F file must also be listed in F - if it's not, a -warning will be issued. - -The current version of the F specification can be found -on CPAN as L. - -=item distsign - -[version 0.16] - -Uses C to create a SIGNATURE file for your -distribution, and adds the SIGNATURE file to the distribution's -MANIFEST. - -=item disttest - -[version 0.05] - -Performs the 'distdir' action, then switches into that directory and runs a -C, followed by the 'build' and 'test' actions in that directory. -Use PERL_MB_OPT or F<.modulebuildrc> to set options that should be applied -during subprocesses - - -=item docs - -[version 0.20] - -This will generate documentation (e.g. Unix man pages and HTML -documents) for any installable items under B that -contain POD. If there are no C or C installation -targets defined (as will be the case on systems that don't support -Unix manpages) no action is taken for manpages. If there are no -C or C installation targets defined no action is -taken for HTML documents. - -=item fakeinstall - -[version 0.02] - -This is just like the C action, but it won't actually do -anything, it will just report what it I have done if you had -actually run the C action. - -=item help - -[version 0.03] - -This action will simply print out a message that is meant to help you -use the build process. It will show you a list of available build -actions too. - -With an optional argument specifying an action name (e.g. C), the 'help' action will show you any POD documentation it can -find for that action. - -=item html - -[version 0.26] - -This will generate HTML documentation for any binary or library files -under B that contain POD. The HTML documentation will only be -installed if the install paths can be determined from values in -C. You can also supply or override install paths on the -command line by specifying C values for the C -and/or C installation targets. - -With an optional C argument set to a false value, you can -skip the search for other documentation to link to, because that can -waste a lot of time if there aren't any links to generate anyway: - - ./Build html --html_links 0 - -=item install - -[version 0.01] - -This action will use C to install the files from -C into the system. See L<"INSTALL PATHS"> -for details about how Module::Build determines where to install -things, and how to influence this process. - -If you want the installation process to look around in C<@INC> for -other versions of the stuff you're installing and try to delete it, -you can use the C parameter, which tells C to -do so: - - ./Build install uninst=1 - -This can be a good idea, as it helps prevent multiple versions of a -module from being present on your system, which can be a confusing -situation indeed. - -=item installdeps - -[version 0.36] - -This action will use the C parameter as a command to install -missing prerequisites. You will be prompted whether to install -optional dependencies. - -The C option defaults to 'cpan' but can be set as an option or in -F<.modulebuildrc>. It must be a shell command that takes a list of modules to -install as arguments (e.g. 'cpanp -i' for CPANPLUS). If the program part is a -relative path (e.g. 'cpan' or 'cpanp'), it will be located relative to the perl -program that executed Build.PL. - - /opt/perl/5.8.9/bin/perl Build.PL - ./Build installdeps --cpan_client 'cpanp -i' - # installs to 5.8.9 - -=item manifest - -[version 0.05] - -This is an action intended for use by module authors, not people -installing modules. It will bring the F up to date with the -files currently present in the distribution. You may use a -F file to exclude certain files or directories from -inclusion in the F. F should contain a bunch -of regular expressions, one per line. If a file in the distribution -directory matches any of the regular expressions, it won't be included -in the F. - -The following is a reasonable F starting point, you can -add your own stuff to it: - - ^_build - ^Build$ - ^blib - ~$ - \.bak$ - ^MANIFEST\.SKIP$ - CVS - -See the L and L actions if you want to find out -what the C action would do, without actually doing anything. - -=item manifest_skip - -[version 0.3608] - -This is an action intended for use by module authors, not people -installing modules. It will generate a boilerplate MANIFEST.SKIP file -if one does not already exist. - -=item manpages - -[version 0.28] - -This will generate man pages for any binary or library files under -B that contain POD. The man pages will only be installed if the -install paths can be determined from values in C. You can -also supply or override install paths by specifying there values on -the command line with the C and C installation -targets. - -=item pardist - -[version 0.2806] - -Generates a PAR binary distribution for use with L or L. - -It requires that the PAR::Dist module (version 0.17 and up) is -installed on your system. - -=item ppd - -[version 0.20] - -Build a PPD file for your distribution. - -This action takes an optional argument C which is used in -the generated PPD file to specify the (usually relative) URL of the -distribution. By default, this value is the distribution name without -any path information. - -Example: - - ./Build ppd --codebase "MSWin32-x86-multi-thread/Module-Build-0.21.tar.gz" - -=item ppmdist - -[version 0.23] - -Generates a PPM binary distribution and a PPD description file. This -action also invokes the C action, so it can accept the same -C argument described under that action. - -This uses the same mechanism as the C action to tar & zip its -output, so you can supply C and/or C parameters to affect -the result. - -=item prereq_data - -[version 0.32] - -This action prints out a Perl data structure of all prerequisites and the versions -required. The output can be loaded again using C. This can be useful for -external tools that wish to query a Build script for prerequisites. - -=item prereq_report - -[version 0.28] - -This action prints out a list of all prerequisites, the versions required, and -the versions actually installed. This can be useful for reviewing the -configuration of your system prior to a build, or when compiling data to send -for a bug report. - -=item pure_install - -[version 0.28] - -This action is identical to the C action. In the future, -though, when C starts writing to the file -F<$(INSTALLARCHLIB)/perllocal.pod>, C won't, and that -will be the only difference between them. - -=item realclean - -[version 0.01] - -This action is just like the C action, but also removes the -C<_build> directory and the C script. If you run the -C action, you are essentially starting over, so you will -have to re-create the C script again. - -=item retest - -[version 0.2806] - -This is just like the C action, but doesn't actually build the -distribution first, and doesn't add F to the load path, and -therefore will test against a I installed version of the -distribution. This can be used to verify that a certain installed -distribution still works, or to see whether newer versions of a -distribution still pass the old regression tests, and so on. - -=item skipcheck - -[version 0.05] - -Reports which files are skipped due to the entries in the -F file (See L for details) - -=item test - -[version 0.01] - -This will use C or C to run any regression -tests and report their results. Tests can be defined in the standard -places: a file called C in the top-level directory, or several -files ending with C<.t> in a C directory. - -If you want tests to be 'verbose', i.e. show details of test execution -rather than just summary information, pass the argument C. - -If you want to run tests under the perl debugger, pass the argument -C. - -If you want to have Module::Build find test files with different file -name extensions, pass the C argument with an array -of extensions, such as C<[qw( .t .s .z )]>. - -If you want test to be run by C, rather than C, -pass the argument C as an array reference of arguments to -pass to the TAP::Harness constructor. - -In addition, if a file called C exists in the top-level -directory, this file will be executed as a Perl script and its output -will be shown to the user. This is a good place to put speed tests or -other tests that don't use the C format for output. - -To override the choice of tests to run, you may pass a C -argument whose value is a whitespace-separated list of test scripts to -run. This is especially useful in development, when you only want to -run a single test to see whether you've squashed a certain bug yet: - - ./Build test --test_files t/something_failing.t - -You may also pass several C arguments separately: - - ./Build test --test_files t/one.t --test_files t/two.t - -or use a C-style pattern: - - ./Build test --test_files 't/01-*.t' - -=item testall - -[version 0.2807] - -[Note: the 'testall' action and the code snippets below are currently -in alpha stage, see -L<"http://www.nntp.perl.org/group/perl.module.build/2007/03/msg584.html"> ] - -Runs the C action plus each of the C actions defined by -the keys of the C parameter. - -Currently, you need to define the ACTION_test$type method yourself and -enumerate them in the test_types parameter. - - my $mb = Module::Build->subclass( - code => q( - sub ACTION_testspecial { shift->generic_test(type => 'special'); } - sub ACTION_testauthor { shift->generic_test(type => 'author'); } - ) - )->new( - ... - test_types => { - special => '.st', - author => ['.at', '.pt' ], - }, - ... - -=item testcover - -[version 0.26] - -Runs the C action using C, generating a -code-coverage report showing which parts of the code were actually -exercised during the tests. - -To pass options to C, set the C<$DEVEL_COVER_OPTIONS> -environment variable: - - DEVEL_COVER_OPTIONS=-ignore,Build ./Build testcover - -=item testdb - -[version 0.05] - -This is a synonym for the 'test' action with the C -argument. - -=item testpod - -[version 0.25] - -This checks all the files described in the C action and -produces C-style output. If you are a module author, -this is useful to run before creating a new release. - -=item testpodcoverage - -[version 0.28] - -This checks the pod coverage of the distribution and -produces C-style output. If you are a module author, -this is useful to run before creating a new release. - -=item versioninstall - -[version 0.16] - -** Note: since C is so new, and since we just recently added -support for it here too, this feature is to be considered -experimental. ** - -If you have the C module installed on your system, you can -use this action to install a module into the version-specific library -trees. This means that you can have several versions of the same -module installed and C a specific one like this: - - use only MyModule => 0.55; - -To override the default installation libraries in C, -specify the C parameter when you run the C script: - - perl Build.PL --versionlib /my/version/place/ - -To override which version the module is installed as, specify the -C parameter when you run the C script: - - perl Build.PL --version 0.50 - -See the C documentation for more information on -version-specific installs. - -=back - - -=head1 OPTIONS - -=head2 Command Line Options - -The following options can be used during any invocation of C -or the Build script, during any action. For information on other -options specific to an action, see the documentation for the -respective action. - -NOTE: There is some preliminary support for options to use the more -familiar long option style. Most options can be preceded with the -C<--> long option prefix, and the underscores changed to dashes -(e.g. C<--use-rcfile>). Additionally, the argument to boolean options is -optional, and boolean options can be negated by prefixing them with -C or C (e.g. C<--noverbose> or C<--no-verbose>). - -=over 4 - -=item quiet - -Suppress informative messages on output. - -=item verbose - -Display extra information about the Build on output. C will -turn off C - -=item cpan_client - -Sets the C command for use with the C action. -See C for more details. - -=item use_rcfile - -Load the F<~/.modulebuildrc> option file. This option can be set to -false to prevent the custom resource file from being loaded. - -=item allow_mb_mismatch - -Suppresses the check upon startup that the version of Module::Build -we're now running under is the same version that was initially invoked -when building the distribution (i.e. when the C script was -first run). As of 0.3601, a mismatch results in a warning instead of -a fatal error, so this option effectively just suppresses the warning. - -=item debug - -Prints Module::Build debugging information to STDOUT, such as a trace of -executed build actions. - -=back - -=head2 Default Options File (F<.modulebuildrc>) - -[version 0.28] - -When Module::Build starts up, it will look first for a file, -F<$ENV{HOME}/.modulebuildrc>. If it's not found there, it will look -in the F<.modulebuildrc> file in the directories referred to by -the environment variables C + C, C, -C, C, C. If the file exists, the options -specified there will be used as defaults, as if they were typed on the -command line. The defaults can be overridden by specifying new values -on the command line. - -The action name must come at the beginning of the line, followed by any -amount of whitespace and then the options. Options are given the same -as they would be on the command line. They can be separated by any -amount of whitespace, including newlines, as long there is whitespace at -the beginning of each continued line. Anything following a hash mark (C<#>) -is considered a comment, and is stripped before parsing. If more than -one line begins with the same action name, those lines are merged into -one set of options. - -Besides the regular actions, there are two special pseudo-actions: the -key C<*> (asterisk) denotes any global options that should be applied -to all actions, and the key 'Build_PL' specifies options to be applied -when you invoke C. - - * verbose=1 # global options - diff flags=-u - install --install_base /home/ken - --install_path html=/home/ken/docs/html - installdeps --cpan_client 'cpanp -i' - -If you wish to locate your resource file in a different location, you -can set the environment variable C to the complete -absolute path of the file containing your options. - -=head2 Environment variables - -=over - -=item MODULEBUILDRC - -[version 0.28] - -Specifies an alternate location for a default options file as described above. - -=item PERL_MB_OPT - -[version 0.36] - -Command line options that are applied to Build.PL or any Build action. The -string is split as the shell would (e.g. whitespace) and the result is -prepended to any actual command-line arguments. - -=back - -=head1 INSTALL PATHS - -[version 0.19] - -When you invoke Module::Build's C action, it needs to figure -out where to install things. The nutshell version of how this works -is that default installation locations are determined from -F, and they may be overridden by using the C -parameter. An C parameter lets you specify an -alternative installation root like F, and a C lets -you specify a temporary installation directory like F in -case you want to create bundled-up installable packages. - -Natively, Module::Build provides default installation locations for -the following types of installable items: - -=over 4 - -=item lib - -Usually pure-Perl module files ending in F<.pm>. - -=item arch - -"Architecture-dependent" module files, usually produced by compiling -XS, L, or similar code. - -=item script - -Programs written in pure Perl. In order to improve reuse, try to make -these as small as possible - put the code into modules whenever -possible. - -=item bin - -"Architecture-dependent" executable programs, i.e. compiled C code or -something. Pretty rare to see this in a perl distribution, but it -happens. - -=item bindoc - -Documentation for the stuff in C