From: Rafael Garcia-Suarez Date: Thu, 25 Oct 2007 09:46:55 +0000 (+0000) Subject: Upgrade to Module::Build 0.2808_01 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=7a8275103724a565c49bc9103575d42057915b64;p=p5sagit%2Fp5-mst-13.2.git Upgrade to Module::Build 0.2808_01 p4raw-id: //depot/perl@32192 --- diff --git a/MANIFEST b/MANIFEST index e25143a..10743b2 100644 --- a/MANIFEST +++ b/MANIFEST @@ -2132,6 +2132,7 @@ lib/Module/Build/Compat.pm Module::Build lib/Module/Build/ConfigData.pm Module::Build lib/Module/Build/Config.pm Module::Build lib/Module/Build/Cookbook.pm Module::Build +lib/Module/Build/Dumper.pm Module::Build lib/Module/Build/ModuleInfo.pm Module::Build lib/Module/Build/Notes.pm Module::Build lib/Module/Build/Platform/aix.pm Module::Build diff --git a/lib/Module/Build.pm b/lib/Module/Build.pm index 7f4408b..6a53ad8 100644 --- a/lib/Module/Build.pm +++ b/lib/Module/Build.pm @@ -227,10 +227,8 @@ 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, and -all the key=value pairs in C are available in - -C<< $self->{config} >>. If the user wishes to override any of the +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 @@ -524,7 +522,7 @@ for a bug report. [version 0.28] This action is identical to the C action. In the future, -though, if C starts writing to the file file +though, when C starts writing to the file F<$(INSTALLARCHLIB)/perllocal.pod>, C won't, and that will be the only difference between them. diff --git a/lib/Module/Build/API.pod b/lib/Module/Build/API.pod index c7b8cbf..2ad6dc5 100644 --- a/lib/Module/Build/API.pod +++ b/lib/Module/Build/API.pod @@ -23,7 +23,7 @@ stabilizes. This method returns a reasonable facsimile of the currently-executing C object representing the current build. You can use -this object to query its C method, inquire about installed +this object to query its L method, inquire about installed modules, and so on. This is a great way to share information between different parts of your build process. For instance, you can ask the user a question during C, then use their answer @@ -55,8 +55,8 @@ C was invoked from. Creates a new Module::Build object. Arguments to the new() method are listed below. Most arguments are optional, but you must provide -either the C argument, or C and one of -C or C. In other words, you must +either the L argument, or L and one of +L or L. In other words, you must provide enough information to determine both a distribution name and version. @@ -68,14 +68,15 @@ version. [version 0.19] An array reference of files to be cleaned up when the C action -is performed. See also the add_to_cleanup() method. +is performed. See also the L +method. =item auto_features [version 0.26] This parameter supports the setting of features (see -L) automatically based on a set of prerequisites. For +L) automatically based on a set of prerequisites. For instance, for a module that could optionally use either MySQL or PostgreSQL databases, you might use C like this: @@ -101,7 +102,7 @@ if there are no failures, the feature will be enabled (set to C<1>). Otherwise the failures will be displayed to the user and the feature will be disabled (set to C<0>). -See the documentation for L for the details of how +See the documentation for L for the details of how requirements can be specified. =item autosplit @@ -109,9 +110,9 @@ requirements can be specified. [version 0.04] An optional C argument specifies a file which should be run -through the C function. If multiple files -should be split, the argument may be given as an array of the files to -split. +through the L function. +If multiple files should be split, the argument may be given as an +array of the files to split. In general I don't consider autosplitting a great idea, because it's not always clear that autosplitting achieves its intended performance @@ -123,13 +124,13 @@ startup. [version 0.28] -The Module::Build class or subclass to use in the build -script. Defaults to "Module::Build" or the class name passed to or -created by a call to C. This property is useful if you're +The Module::Build class or subclass to use in the build script. +Defaults to "Module::Build" or the class name passed to or created by +a call to L. This property is useful if you're writing a custom Module::Build subclass and have a bootstrapping problem--that is, your subclass requires modules that may not be installed when C is executed, but you've listed in -C so that they should be available when C<./Build> is +L so that they should be available when C<./Build> is executed. =item build_requires @@ -188,7 +189,7 @@ for the details of how requirements can be specified. This parameter lets you use Module::Build::Compat during the C (or C) action to automatically create a Makefile.PL for compatibility with ExtUtils::MakeMaker. The parameter's value -should be one of the styles named in the Module::Build::Compat +should be one of the styles named in the L documentation. =item create_readme @@ -243,8 +244,8 @@ to a module name, so C can be set independently. [version 0.11] -Specifies a version number for the distribution. See C -or C for ways to have this set automatically from a +Specifies a version number for the distribution. See L +or L for ways to have this set automatically from a C<$VERSION> variable in a module. One way or another, a version number needs to be set. @@ -253,11 +254,11 @@ number needs to be set. [version 0.11] Specifies a file to look for the distribution version in. Most -authors won't need to set this directly, they can use C +authors won't need to set this directly, they can use L to set it to a reasonable default. The version is extracted from the specified file according to the same -rules as C and C. It involves finding +rules as L and C. It involves finding the first line that matches the regular expression /([\$*])(([\w\:\']*)\bVERSION)\b.*\=/ @@ -280,9 +281,9 @@ omitted, the F spec says that installation tools should treat it as 1 (true), because this is a safer way to behave. Currently C doesn't actually do anything with this flag -- it's up to higher-level tools like C to do -something useful with it. It can potentially bring lots of security, -packaging, and convenience improvements. +- it's up to higher-level tools like C to do something useful +with it. It can potentially bring lots of security, packaging, and +convenience improvements. =item extra_compiler_flags @@ -317,7 +318,7 @@ To link your XS code against glib you might write something like: You can pass arbitrary command line options to F or F, and they will be stored in the Module::Build object and can -be accessed via the C method. However, sometimes you want +be accessed via the L method. However, sometimes you want more flexibility out of your argument processing than this allows. In such cases, use the C parameter to pass in a hash reference of argument specifications, and the list of arguments to @@ -428,50 +429,55 @@ Specifies the licensing terms of your distribution. Valid options include: =item apache The distribution is licensed under the Apache Software License -(http://opensource.org/licenses/apachepl.php). +(L). =item artistic The distribution is licensed under the Artistic License, as specified -by the F file in the standard perl distribution. +by the F file in the standard Perl distribution. + +=item artistic_2 + +The distribution is licensed under the Artistic 2.0 License +(L.) =item bsd The distribution is licensed under the BSD License -(http://www.opensource.org/licenses/bsd-license.php). +(L). =item gpl -The distribution is licensed under the terms of the Gnu General -Public License (http://www.opensource.org/licenses/gpl-license.php). +The distribution is licensed under the terms of the GNU General +Public License (L). =item lgpl -The distribution is licensed under the terms of the Gnu Lesser +The distribution is licensed under the terms of the GNU Lesser General Public License -(http://www.opensource.org/licenses/lgpl-license.php). +(L). =item mit The distribution is licensed under the MIT License -(http://opensource.org/licenses/mit-license.php). +(L). =item mozilla The distribution is licensed under the Mozilla Public -License. (http://opensource.org/licenses/mozilla1.0.php or -http://opensource.org/licenses/mozilla1.1.php) +License. (L or +L) =item open_source The distribution is licensed under some other Open Source Initiative-approved license listed at -http://www.opensource.org/licenses/ . +L. =item perl The distribution may be copied and redistributed under the same terms -as perl itself (this is by far the most common licensing option for +as Perl itself (this is by far the most common licensing option for modules on CPAN). This is a dual license, in which the user may choose between either the GPL or the Artistic license. @@ -515,6 +521,8 @@ A hash of key/value pairs that should be added to the F file during the C action. Any existing entries with the same names will be overridden. +See the L section for details. + =item meta_merge [version 0.28] @@ -529,6 +537,8 @@ completely blow away the existing hash or array value, but C will merge the supplied data into the existing hash or array value. +See the L section for details. + =item module_name [version 0.03] @@ -618,7 +628,7 @@ files in your distribution. [version 0.08] -This is just like the C argument, except that modules listed +This is just like the L argument, except that modules listed in this section aren't essential, just a good idea. We'll just print a friendly warning if one of these modules aren't found, but we'll continue running. @@ -651,7 +661,7 @@ that the current module depends on. One note: currently C doesn't actually I the user to have dependencies installed, it just strongly urges. In the -future we may require it. There's also a C section for +future we may require it. There's also a L section for things that aren't absolutely required. Automated tools like CPAN.pm should refuse to install a module if one @@ -672,7 +682,7 @@ for the details of how requirements can be specified. [version 0.18] An optional parameter specifying a set of files that should be -installed as executable perl scripts when the module is installed. +installed as executable Perl scripts when the module is installed. May be given as an array reference of the files, or as a hash reference whose keys are the files (and whose values will currently be ignored). @@ -689,7 +699,7 @@ though it will continue to exist for several version releases. [version 0.16] -If a true value is specified for this parameter, C +If a true value is specified for this parameter, L will be used (via the 'distsign' action) to create a SIGNATURE file for your distribution during the 'distdir' action, and to add the SIGNATURE file to the MANIFEST (therefore, don't add it yourself). @@ -824,7 +834,7 @@ first argument. [version 0.28] -Invokes the C module on the C<$from> file, sending the +Invokes the L module on the C<$from> file, sending the output to the C directory inside C<$to>. C<$to> is typically the C directory. @@ -852,7 +862,7 @@ prerequisites that were passed to the C method. This method returns a hash reference indicating whether a version dependency on a certain module is satisfied. The C<$module> argument is given as a string like C<"Data::Dumper"> or C<"perl">, and the -C<$version> argument can take any of the forms described in L +C<$version> argument can take any of the forms described in L above. This allows very fine-grained version checking. The returned hash reference has the following structure: @@ -873,16 +883,16 @@ for the case when C<$module> isn't installed at all. This method may be called either as an object method (C<< $build->check_installed_status($module, $version) >>) -or as a class method +or as a class method (C<< Module::Build->check_installed_status($module, $version) >>). =item check_installed_version($module, $version) [version 0.05] -Like C, but simply returns true or false -depending on whether module C<$module> satisfies the dependency -C<$version>. +Like L, +but simply returns true or false depending on whether module +C<$module> satisfies the dependency C<$version>. If the check succeeds, the return value is the actual version of C<$module> installed on the system. This allows you to do the @@ -931,7 +941,7 @@ out to C. With a single argument C<$key>, returns the value associated with that key in the C hash, including any changes the author or user -has specified. +has specified. With C<$key> and C<$value> arguments, sets the value for future callers of C. @@ -948,7 +958,7 @@ resource hog and violates encapsulation. With a single argument, returns the value of the configuration variable C<$name>. With two arguments, sets the given configuration -variable to the given value. The value may be any perl scalar that's +variable to the given value. The value may be any Perl scalar that's serializable with C. For instance, if you write a module that can use a MySQL or PostgreSQL back-end, you might create configuration variables called C and @@ -960,7 +970,7 @@ will be available for querying during the build/test process and after installation via the generated C<...::ConfigData> module, as C<< ...::ConfigData->config($name) >>. -The C and C methods represent +The L and C methods represent Module::Build's main support for configuration of installed modules. See also L. @@ -1016,13 +1026,13 @@ when the C action is performed. Among the files created in C<_build/> is a F<_build/prereqs> file containing the set of prerequisites for this distribution, as a hash of hashes. This file may be C-ed to obtain the authoritative -set of prereqs, which might be different from the contents of META.yml -(because F might have set them dynamically). But fancy -developers take heed: do not put any fancy custom runtime code in the -F<_build/prereqs> file, leave it as a static declaration containing -only strings and numbers. Similarly, do not alter the structure of -the internal C<< $self->{properties}{requires} >> (etc.) data members, -because that's where this data comes from. +set of prereqs, which might be different from the contents of +F (because F might have set them dynamically). +But fancy developers take heed: do not put any fancy custom runtime +code in the F<_build/prereqs> file, leave it as a static declaration +containing only strings and numbers. Similarly, do not alter the +structure of the internal C<< $self->{properties}{requires} >> (etc.) +data members, because that's where this data comes from. =item current_action() @@ -1037,7 +1047,7 @@ return "code" while that dependency is being executed. Once that action has completed, current_action() will again return "test". If you need to know the name of the original action invoked by the -user, see L below. +user, see L below. =item depends_on(@actions) @@ -1056,9 +1066,10 @@ C or something, but for better or worse (perhaps better!) we were still thinking in C-like dependency terms when we created this method. -See also C. The main distinction between the two is that -C is meant to call an action from inside another action, -whereas C is meant to set the very top action in motion. +See also L. The main +distinction between the two is that C is meant to call +an action from inside another action, whereas C is meant +to set the very top action in motion. =item dir_contains($first_dir, $second_dir) @@ -1086,9 +1097,10 @@ This method is intended to be used to programmatically invoke build actions, e.g. by applications controlling Module::Build-based builds rather than by subclasses. -See also C. The main distinction between the two is that -C is meant to call an action from inside another action, -whereas C is meant to set the very top action in motion. +See also L. The main +distinction between the two is that C is meant to call +an action from inside another action, whereas C is meant +to set the very top action in motion. =item dist_dir() @@ -1147,7 +1159,7 @@ installed and configured. Features set in this way using the Module::Build object will be available for querying during the build/test process and after -installation via the generated C<...::ConfigData> module, as +installation via the generated C<...::ConfigData> module, as C<< ...::ConfigData->feature($name) >>. The C and C methods represent @@ -1193,7 +1205,7 @@ Assigning the value C to an element causes it to be removed. [version 0.28] Returns the directory in which items of type C<$type> (e.g. C, -C, C, or anything else returned by the C +C, C, or anything else returned by the L method) will be installed during the C action. Any settings for C, C, and C are taken into account when determining the return value. @@ -1242,11 +1254,12 @@ exist. This is the name of the original action invoked by the user. This value is set when the user invokes F, the F script, -or programatically through the L method. It does not -change as sub-actions are executed as dependencies are evaluated. +or programatically through the L +method. It does not change as sub-actions are executed as +dependencies are evaluated. To get the name of the currently executing dependency, see -L above. +L above. =item notes() @@ -1474,7 +1487,7 @@ Examples: # All the *.pm files in lib/ $m->rscan_dir('lib', qr/\.pm$/) - + # All the files in blib/ that aren't *.html files $m->rscan_dir('blib', sub {-f $_ and not /\.html$/}); @@ -1589,6 +1602,8 @@ accessor methods for the following properties: =item config_dir() +=item configure_requires() + =item conflicts() =item create_makefile_pl() @@ -1666,6 +1681,35 @@ accessor methods for the following properties: =back +=head1 MODULE METADATA + +If you would like to add other useful metadata, C +supports this with the C and C arguments to +L. The authoritative list of supported metadata can be found at +L, but for +convenience - here are a few of the more useful ones: + +=over 4 + +=item keywords + +For describing the distribution using keyword (or "tags") in order to +make CPAN.org indexing and search more efficient and useful. + +See L. + +=item resources + +A list of additional resources available for users of the +distribution. This can include links to a homepage on the web, a +bugtracker, the repository location, a even subscription page for the +distribution mailing list. + +See L. + +=back + + =head1 AUTHOR Ken Williams diff --git a/lib/Module/Build/Authoring.pod b/lib/Module/Build/Authoring.pod index b0b7f37..871effd 100644 --- a/lib/Module/Build/Authoring.pod +++ b/lib/Module/Build/Authoring.pod @@ -141,20 +141,51 @@ method. =head1 PREREQUISITES -There are three basic types of prerequisites that can be defined: 1) -"requires" - are versions of modules that are required for certain -functionality to be available; 2) "recommends" - are versions of -modules that are recommended to provide enhanced functionality; and 3) -"conflicts" - are versions of modules that conflict with, and that can -cause problems with the distribution. +=head2 Types of prerequisites -Each of the three types of prerequisites listed above can be applied -to different aspects of the Build process. For the module distribution -itself you simply define "requires", "recommends", or "conflicts". The -types can also apply to other aspects of the Build process. Currently, -only "build_requires" is defined which is used for modules which are -required during the Build process. +To specify what versions of other modules are used by this +distribution, several types of prerequisites can be defined with the +following parameters: +=over 3 + +=item configure_requires + +Items that must be installed I configuring this distribution +(i.e. before running the F script). This might be a +specific minimum version of C or any other module the +F needs in order to do its stuff. Clients like C +or C will be expected to pick C out of the +F file and install these items before running the +C. + +*TODO* auto-add M::B? In what circumstances? + +=item build_requires + +Items that are necessary for building and testing this distribution, +but aren't necessary after installation. This can help users who only +want to install these items temporarily. It also helps reduce the +size of the CPAN dependency graph if everything isn't smooshed into +C. + +=item requires + +Items that are necessary for basic functioning. + +=item recommends + +Items that are recommended for enhanced functionality, but there are +ways to use this distribution without having them installed. You +might also think of this as "can use" or "is aware of" or "changes +behavior in the presence of". + +=item conflicts + +Items that can cause problems with this distribution when installed. +This is pretty rare. + +=back =head2 Format of prerequisites @@ -168,7 +199,7 @@ the module names and the values are version specifiers: perl => '5.6.0' }, -These four version specifiers have different effects. The value +The above four version specifiers have different effects. The value C<'2.4'> means that B version 2.4 of C must be installed. The value C<0> means that B version of C is acceptable, even if C doesn't define a version. The @@ -182,6 +213,11 @@ interpreter that are supported by your module. The same version dependency-checking semantics are available, except that we also understand perl's new double-dotted version numbers. +=head2 XS Extensions + +Modules which need to compile XS code should list C +as a C element. + =head1 SAVING CONFIGURATION INFORMATION @@ -210,8 +246,8 @@ library (thus the C part) into perl extensions (thus the C part). These days, C has largely been superseded by modules like -C, C, and C. -They have varying degrees of support for C. +C, and C. They have varying +degrees of support for C. =head1 AUTOMATION diff --git a/lib/Module/Build/Base.pm b/lib/Module/Build/Base.pm index 58d7539..3090084 100644 --- a/lib/Module/Build/Base.pm +++ b/lib/Module/Build/Base.pm @@ -1,17 +1,19 @@ package Module::Build::Base; use strict; +use vars qw($VERSION); +$VERSION = '0.2808_01'; +$VERSION = eval $VERSION; BEGIN { require 5.00503 } use Carp; -use Config; use File::Copy (); use File::Find (); use File::Path (); use File::Basename (); use File::Spec 0.82 (); use File::Compare (); -use Data::Dumper (); +use Module::Build::Dumper (); use IO::File (); use Text::ParseWords (); @@ -30,13 +32,13 @@ sub new { die "Too early to specify a build action '$self->{action}'. Do 'Build $self->{action}' instead.\n" if $self->{action} && $self->{action} ne 'Build_PL'; - $self->dist_name; - $self->dist_version; - $self->check_manifest; $self->check_prereq; $self->check_autofeatures; + $self->dist_name; + $self->dist_version; + $self->_set_install_paths; $self->_find_nested_builds; @@ -384,6 +386,17 @@ sub _perl_is_same { return $self->_backticks(@cmd) eq Config->myconfig; } +# cache _discover_perl_interpreter() results +{ + my $known_perl; + sub find_perl_interpreter { + my $self = shift; + + return $known_perl if defined($known_perl); + return $known_perl = $self->_discover_perl_interpreter; + } +} + # Returns the absolute path of the perl interperter used to invoke # this process. The path is derived from $^X or $Config{perlpath}. On # some platforms $^X contains the complete absolute path of the @@ -393,8 +406,8 @@ sub _perl_is_same { # executable extension on platforms that use one. It's a fatal error # if the interpreter can't be found because it can result in undefined # behavior by routines that depend on it (generating errors or -# invoking the wrong perl. -sub find_perl_interpreter { +# invoking the wrong perl.) +sub _discover_perl_interpreter { my $proto = shift; my $c = ref($proto) ? $proto->{config} : 'Module::Build::Config'; @@ -431,7 +444,7 @@ sub find_perl_interpreter { } else { - # Try 3.B, First look in $Config{perlpath}, then search the users + # Try 3.B, First look in $Config{perlpath}, then search the user's # PATH. We do not want to do either if we are running from an # uninstalled perl in a perl source tree. @@ -447,7 +460,7 @@ sub find_perl_interpreter { my $exe = $c->get('exe_ext'); foreach my $thisperl ( @potential_perls ) { - if (defined $exe and $proto->os_type ne 'VMS') { + if (defined $exe) { $thisperl .= $exe unless $thisperl =~ m/$exe$/i; } @@ -576,7 +589,7 @@ sub features { return wantarray ? %features : \%features; } -BEGIN { *feature = \&features } +BEGIN { *feature = \&features } # Alias sub _mb_feature { my $self = shift; @@ -782,6 +795,7 @@ __PACKAGE__->add_property($_ => {}) for qw( meta_merge original_prefix prefix_relpaths + configure_requires ); __PACKAGE__->add_property($_) for qw( @@ -951,7 +965,7 @@ sub dist_version { die ("Can't determine distribution version, must supply either 'dist_version',\n". "'dist_version_from', or 'module_name' parameter") - unless $p->{dist_version}; + unless defined $p->{dist_version}; return $p->{dist_version}; } @@ -1026,8 +1040,12 @@ sub _write_data { my $file = $self->config_file($filename); my $fh = IO::File->new("> $file") or die "Can't create '$file': $!"; - local $Data::Dumper::Terse = 1; - print $fh ref($data) ? Data::Dumper::Dumper($data) : $data; + unless (ref($data)) { # e.g. magicnum + print $fh $data; + return; + } + + print {$fh} Module::Build::Dumper->_data_dump($data); } sub write_config { @@ -1186,6 +1204,7 @@ sub perl_version { sub perl_version_to_float { my ($self, $version) = @_; + return $version if grep( /\./, $version ) < 2; $version =~ s/\./../; $version =~ s/\.(\d+)/sprintf '%03d', $1/eg; return $version; @@ -1219,7 +1238,7 @@ sub check_installed_status { } $status{have} = $pm_info->version(); - if ($spec and !$status{have}) { + if ($spec and !defined($status{have})) { @status{ qw(have message) } = (undef, "Couldn't find a \$VERSION in prerequisite $modname"); return \%status; } @@ -1335,7 +1354,7 @@ sub print_build_script { my $case_tolerant = 0+(File::Spec->can('case_tolerant') && File::Spec->case_tolerant); $q{base_dir} = uc $q{base_dir} if $case_tolerant; - $q{base_dir} = Win32::GetShortPathName($q{base_dir}) if $^O eq 'MSWin32'; + $q{base_dir} = Win32::GetShortPathName($q{base_dir}) if $self->is_windowsish; $q{magic_numfile} = $self->config_file('magicnum'); @@ -1677,14 +1696,8 @@ sub read_args { return \%args, $action; } - -# (bash shell won't expand tildes mid-word: "--foo=~/thing") -# TODO: handle ~user/foo -sub _detildefy { - my ($self, $arg) = @_; - - return $arg =~ /^~/ ? (glob $arg)[0] : $arg; -} +# Default: do nothing. Overridden for Unix & Windows. +sub _detildefy {} # merge Module::Build argument lists that have already been parsed @@ -1980,7 +1993,8 @@ sub prereq_report { my $vspace = q{ } x ($ver_len - length $mod->{need}); my $f = $mod->{ok} ? ' ' : '!'; $output .= - " $f $mod->{name} $space $mod->{need} $vspace $mod->{have}\n"; + " $f $mod->{name} $space $mod->{need} $vspace ". + (defined($mod->{have}) ? $mod->{have} : "")."\n"; } } return $output; @@ -2259,7 +2273,7 @@ sub process_PL_files { while (my ($file, $to) = each %$files) { unless ($self->up_to_date( $file, $to )) { - $self->run_perl_script($file, [], [@$to]); + $self->run_perl_script($file, [], [@$to]) or die "$file failed"; $self->add_to_cleanup(@$to); } } @@ -2865,7 +2879,7 @@ sub ACTION_ppmdist { File::Spec->abs2rel( File::Spec->rel2abs( $file ), File::Spec->rel2abs( $dir ) ); my $to_file = - File::Spec->catfile( $ppm, 'blib', + File::Spec->catdir( $ppm, 'blib', exists( $types{$type} ) ? $types{$type} : $type, $rel_file ); $self->copy_if_modified( from => $file, to => $to_file ); @@ -2879,10 +2893,8 @@ sub ACTION_ppmdist { # create a tarball; # the directory tar'ed must be blib so we need to do a chdir first - my $start_wd = $self->cwd; - chdir( $ppm ) or die "Can't chdir to $ppm"; - $self->make_tarball( 'blib', File::Spec->catfile( $start_wd, $ppm ) ); - chdir( $start_wd ) or die "Can't chdir to $start_wd"; + my $target = File::Spec->catfile( File::Spec->updir, $ppm ); + $self->_do_in_dir( $ppm, sub { $self->make_tarball( 'blib', $target ) } ); $self->depends_on( 'ppd' ); @@ -2979,13 +2991,17 @@ sub _sign_dir { $self->_add_to_manifest($manifest, "SIGNATURE Added here by Module::Build"); } - # We protect the signing with an eval{} to make sure we get back to - # the right directory after a signature failure. Would be nice if - # Module::Signature took a directory argument. + # Would be nice if Module::Signature took a directory argument. + $self->_do_in_dir($dir, sub {local $Module::Signature::Quiet = 1; Module::Signature::sign()}); +} + +sub _do_in_dir { + my ($self, $dir, $do) = @_; + my $start_dir = $self->cwd; chdir $dir or die "Can't chdir() to $dir: $!"; - eval {local $Module::Signature::Quiet = 1; Module::Signature::sign()}; + eval {$do->()}; my @err = $@ ? ($@) : (); chdir $start_dir or push @err, "Can't chdir() back to $start_dir: $!"; die join "\n", @err if @err; @@ -3124,18 +3140,18 @@ sub ACTION_disttest { $self->depends_on('distdir'); - my $start_dir = $self->cwd; - my $dist_dir = $self->dist_dir; - chdir $dist_dir or die "Cannot chdir to $dist_dir: $!"; - # XXX could be different names for scripts + $self->_do_in_dir + ( $self->dist_dir, + sub { + # XXX could be different names for scripts - $self->run_perl_script('Build.PL') # XXX Should this be run w/ --nouse-rcfile - or die "Error executing 'Build.PL' in dist directory: $!"; - $self->run_perl_script('Build') - or die "Error executing 'Build' in dist directory: $!"; - $self->run_perl_script('Build', [], ['test']) - or die "Error executing 'Build test' in dist directory"; - chdir $start_dir; + $self->run_perl_script('Build.PL') # XXX Should this be run w/ --nouse-rcfile + or die "Error executing 'Build.PL' in dist directory: $!"; + $self->run_perl_script('Build') + or die "Error executing 'Build' in dist directory: $!"; + $self->run_perl_script('Build', [], ['test']) + or die "Error executing 'Build test' in dist directory"; + }); } sub _write_default_maniskip { @@ -3256,27 +3272,26 @@ sub script_files { return $_ = {$_ => 1}; } - return $_ = { map {$_,1} $self->_files_in( File::Spec->catdir( $self->base_dir, 'bin' ) ) }; + return $_ = { map {$_,1} $self->_files_in('bin') }; } BEGIN { *scripts = \&script_files; } { - my %licenses = - ( - perl => 'http://dev.perl.org/licenses/', - gpl => 'http://www.opensource.org/licenses/gpl-license.php', - apache => 'http://apache.org/licenses/LICENSE-2.0', - artistic => 'http://opensource.org/licenses/artistic-license.php', - lgpl => 'http://opensource.org/licenses/artistic-license.php', - bsd => 'http://www.opensource.org/licenses/bsd-license.php', - gpl => 'http://www.opensource.org/licenses/gpl-license.php', - mit => 'http://opensource.org/licenses/mit-license.php', - mozilla => 'http://opensource.org/licenses/mozilla1.1.php', - open_source => undef, - unrestricted => undef, - restrictive => undef, - unknown => undef, - ); + my %licenses = ( + perl => 'http://dev.perl.org/licenses/', + apache => 'http://apache.org/licenses/LICENSE-2.0', + artistic => 'http://opensource.org/licenses/artistic-license.php', + artistic_2 => 'http://opensource.org/licenses/artistic-license-2.0.php', + lgpl => 'http://opensource.org/licenses/lgpl-license.php', + bsd => 'http://opensource.org/licenses/bsd-license.php', + gpl => 'http://opensource.org/licenses/gpl-license.php', + mit => 'http://opensource.org/licenses/mit-license.php', + mozilla => 'http://opensource.org/licenses/mozilla1.1.php', + open_source => undef, + unrestricted => undef, + restrictive => undef, + unknown => undef, + ); sub valid_licenses { return \%licenses; } @@ -3382,7 +3397,16 @@ sub prepare_metadata { $node->{resources}{license} = $url; } - foreach ( @{$self->prereq_action_types} ) { + if (exists $p->{configure_requires}) { + foreach my $spec (keys %{$p->{configure_requires}}) { + warn ("Warning: $spec is listed in 'configure_requires', but ". + "it is not found in any of the other prereq fields.\n") + unless grep exists $p->{$_}{$spec}, + grep !/conflicts$/, @{$self->prereq_action_types}; + } + } + + foreach ( 'configure_requires', @{$self->prereq_action_types} ) { if (exists $p->{$_} and keys %{ $p->{$_} }) { $add_node->($_, $p->{$_}); } diff --git a/lib/Module/Build/Changes b/lib/Module/Build/Changes index 14407d4..fd84408 100644 --- a/lib/Module/Build/Changes +++ b/lib/Module/Build/Changes @@ -1,5 +1,152 @@ Revision history for Perl extension Module::Build. + - All .pm files in the Module-Build distribution (except for + M::B::Version.pm, which is kind of tied to version.pm) now have the + same $VERSION number explicitly specified. + + - When checking prerequisites, the required version of perl is now + checked before we start finding the $VERSION declaration of the + distribution, which results in much more intuitive error messages + e.g. if the author is using 5.6-isms in their declaration but the + user doesn't have 5.6. [Slaven Rezic] + + - Added 'artistic_2' license, corrected 'lgpl' license url (bug #29783) + [David Thomas] + + - VMS find_perl_interpreter() is just $^X (bug #29810) [Craig A. Berry] + + - Some large VMS fixes, mostly having to do with the non-case- + preserving nature of most VMS filesystems, but also correcting for + illegal characters in VMS file specs. [John E. Malmberg and Craig + A. Berry] + + - Fixed the _detildefy() method on VMS. [John E. Malmberg and Craig + A. Berry] + + - We now use a much more reliable method when Data::Dumper-ing saved + state data. [Yves] + + - When a module had 0.000 as its version, a few places in the code + thought the module had no version at all. This is now + fixed. [Andrew "Zefram" Main] + + - When finding the default set of script_files, we now compute them + as relative paths, not absolute. [Spotted by Curtis "Ovid" Poe] + + - Got rid of a call to eliminate_macros, which isn't needed in + Module::Build since there is no external make utility involved. + Override expand_test_dir to make up for the fact that the + home-grown glob() returns absolute, not relative, paths. [Craig + A. Berry] + + - Fixed a catdir() that needed to be catfile() in the .packlist + creation code. [John E. Malmberg] + + - If a *.PL file ended abnormally during the build, processing should + have stopped, but it didn't. Fixed. [Matthew Cast and David + Golden] + + - Module::Build::Compat adds "require 5.XXXXX" to Makefile.PL when + 'perl' is specified as a 'requires' prerequisite [David Golden] + + - Refactored t/compat.t for modularity and transparency; added + labels for all tests; supressed subprocess output to + STDOUT and STDERR [David Golden] + + - Fixed bug in perl_version_to_float when version is already a float + [David Golden] + + - Removed a mention of $build->{config} from the documentation, the + official interface to Config.pm settings is now via the + $build->config() and has been for some time. [Suggested by Michael + Schwern] + + - Tweaked some text in the Cookbook to bring it into the modern age, + and added a recipe for accessing Config.pm settings. [Ibid] + + - Lots of POD link/readability improvements to the Module::Build::API + documentation [Salve J. Nilsen] + + - Added configure_requires as a new type of prereq. [Suggested by Adam + Kennedy] + + - Patch 31156 from bleadperl: some filename dot and extension help + for Module::Build on VMS. [Craig Berry] + + - Reworked the _detildefy() method so it doesn't depend on glob() + anymore. This gets rid of a problem with spaces or other special + shell characters in things like 'prefix' or 'install_path' + entries. [Prodding by Eric Wilhelm] + + - Added midnightbsd to the list of Unix-like OSes we know about + [Rafael Garcia-Suarez] + +0.2808 - Sat Apr 28 12:59:43 2007 + + - Added is_vmsish(), is_windowsish(), and is_unixish() boolean + convenience functions. Fixes some test failures on platforms where + $^O is set to a value we don't know about (like 'gnu'). + + - Upgraded to version.pm 0.7203. [John Peacock] + + - Support get_action_docs() =head2 style. [ewilhelm] + + - Workaround Test::Pod::Coverage @INC bug. [Eric Wilhelm] + + - Fixed the command-line args --extra_compiler_flags and + --extra_linker_flags so they properly shell-split their arguments. + +0.2807 - Sat Mar 24 22:19:02 2007 + + - Upgraded to version.pm 0.71. [John Peacock] + + - Removed a couple small constructs in the tests ("use warnings;" and + "qw$foo bar$[1]") that caused test failures under perl 5.005. + + - Added support for an explicit default value of undef in prompt(). + [Eric Wilhelm] + + - Improved our prompt() method, which could sometimes hang before the + user got a chance to see a prompt. [Andreas Koenig] + + - Added a note about --allow_mb_mismatch to the error message that + happens right before someone might want to use that parameter. + + - Added DragonflyBSD to the list of known Unix OSes. + + - get_action_docs() dies on error rather than twiddling $@ + + - Made ModuleInfo's _evaluate_version_line() compatible with 'use + version ...$VERSION' lines. [Eric Wilhelm] + + - Added some verbiage in Module::Build::API that officially blesses + the _build/prereqs file for external consumption. [Suggested by Andreas Koenig] + + - Added test profiles support via the test_types property and "testall" + target. [Eric Wilhelm, Jeff Lavallee] + + - Use syscopy() on OS/2 in copy_if_modified() so we make sure to + overwrite any existing target file. [Ilya Zakharevich] + + - Removed seemingly silly '~~' test in t/tilde.t. + + - In our test-time utility library t/lib/MBTest.pm, we need to know + about a few .exe-like extensions on OS/2. [Ilya Zakharevich] + + - In t/ppm.t, use DynaLoader::mod2fname() (if available) to determine + the correct translation of our test module's name into a DLL + name. [Ilya Zakharevich] + + - Avoid an unlink() error on OS/2 when fixing shebang lines. [Ilya + Zakharevich] + + - When we're protecting the world from the evils of long RedHat + $ENV{PERL5LIB} variables, don't assume $ENV{PERL5LIB} is already + defined. This gets rid of a huge number of warnings for some + people. [Dave Rolsky] + +0.2806 - Fri Dec 15 22:20:14 2006 + - On some systems (haven't identified the actual problem yet) $ENV{PERL5LIB} can grow to enormous enough sizes that we can't launch any more subprocesses because the environment table is full. diff --git a/lib/Module/Build/Compat.pm b/lib/Module/Build/Compat.pm index c64dfc0..d1bc725 100644 --- a/lib/Module/Build/Compat.pm +++ b/lib/Module/Build/Compat.pm @@ -2,7 +2,7 @@ package Module::Build::Compat; use strict; use vars qw($VERSION); -$VERSION = '0.03'; +$VERSION = '0.2808_01'; use File::Spec; use IO::File; @@ -42,6 +42,13 @@ sub create_makefile_pl { print {$fh} "# Note: this file was auto-generated by ", __PACKAGE__, " version $VERSION\n"; + # Minimum perl version should be specified as "require 5.XXXXXX" in + # Makefile.PL + my $requires = $build->requires; + if ( my $minimum_perl = $requires->{perl} ) { + print {$fh} "require $minimum_perl;\n"; + } + # If a *bundled* custom subclass is being used, make sure we add its # directory to @INC. my $subclass_load = ''; diff --git a/lib/Module/Build/Config.pm b/lib/Module/Build/Config.pm index ccf58d9..76b92b9 100644 --- a/lib/Module/Build/Config.pm +++ b/lib/Module/Build/Config.pm @@ -1,6 +1,9 @@ package Module::Build::Config; use strict; +use vars qw($VERSION); +$VERSION = '0.2808_01'; +$VERSION = eval $VERSION; use Config; sub new { diff --git a/lib/Module/Build/Cookbook.pm b/lib/Module/Build/Cookbook.pm index 03341fa..ba721b9 100644 --- a/lib/Module/Build/Cookbook.pm +++ b/lib/Module/Build/Cookbook.pm @@ -9,19 +9,15 @@ Module::Build::Cookbook - Examples of Module::Build Usage =head1 DESCRIPTION C isn't conceptually very complicated, but examples are -always helpful. I got the idea for writing this cookbook when -attending Brian Ingerson's "Extreme Programming Tools for Module -Authors" presentation at YAPC 2003, when he said, straightforwardly, -"Write A Cookbook." - -The definitional of how stuff works is in the main C -documentation. It's best to get familiar with that too. +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 The basic installation recipe for modules that use Module::Build +=head2 Installing modules that use Module::Build In most cases, you can just issue the following commands: @@ -57,35 +53,42 @@ 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 C, so +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 -=head2 Making a CPAN.pm-compatible distribution +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: -New versions of CPAN.pm understand how to use a F script, -but old versions don't. If you want to help users who have old -versions, do the following: + perl Build.PL --config cc=gcc --config ld=gcc -Create a file in your distribution named F, with the -following contents: +Inside the C script the same thing can be accomplished by +passing values for the C parameter to C: - use Module::Build::Compat; - Module::Build::Compat->run_build_pl(args => \@ARGV); - Module::Build::Compat->write_makefile(); + my $build = Module::Build->new + ( + ... + config => { cc => 'gcc', ld => 'gcc' }, + ... + ); -Now CPAN will work as usual, i.e.: `perl Makefile.PL`, `make`, `make -test`, and `make install`, provided the end-user already has -C installed. +In custom build code, the same thing can be accomplished by calling +the L method: -If the end-user might not have C installed, it's -probably best to supply a "traditional" F. The -C module has some very helpful tools for -keeping a F in sync with a F. See its -documentation, and also the C parameter to the -C<< Module::Build->new() >> method. + $build->config( cc => 'gcc' ); # Set + $build->config( ld => 'gcc' ); # Set + ... + my $linker = $build->config('ld'); # Get =head2 Installing modules using the programmatic interface @@ -131,7 +134,7 @@ F 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: +C or C parameters: ./Build install --install_base /foo/bar @@ -147,7 +150,7 @@ 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 installation behaviors. +differing (and in some cases quite strange) installation behaviors. The following installation flags are equivalent between ExtUtils::MakeMaker and Module::Build. @@ -178,10 +181,10 @@ You can install into the same location with Module::Build using this: =head3 C vs C -The behavior of C is complicated and depends closely on +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, its difficult to document +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 @@ -206,7 +209,7 @@ informative output: ./Build test --test_files t/mytest.t --verbose 1 -I run this so frequently that I actually define the following shell alias: +I run this so frequently that I define the following shell alias: alias t './Build test --verbose 1 --test_files' @@ -216,6 +219,24 @@ 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 @@ -241,8 +262,7 @@ C code. 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. Assuming the data doesn't need to -be created on the fly, the best place for it to end up is probably as +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: @@ -260,9 +280,9 @@ 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 in the C directory, you can -explicitly say where they are, just as you'd do with F<.pm> or F<.pod> -files: +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 @@ -276,8 +296,8 @@ files: 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 create a special method to do so, named -C: +want to subclass C and create a special method to +process them, named C: use Module::Build; my $class = Module::Build->subclass(code => <<'EOF'); @@ -300,20 +320,20 @@ 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 certainly +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