Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Lots of spelling fixes in the POD (RT#45528)

git-svn-id: http://svn.perl.org/modules/Module-Build/trunk@12877 50811bd7-b8ce-0310-adc1-d9db26280581
  • Loading branch information...
commit f09c7075f0d58508c964bee92b5f1881ad94eec2 1 parent 6b9899d
@kenahoo kenahoo authored
View
2  .perltidyrc
@@ -20,7 +20,7 @@
--square-bracket-tightness=2
--brace-tightness=2
-# who uses space before the peterbuilt?
+# who uses space before the peterbilt?
--nohanging-side-comments
--nospace-for-semicolon
--indent-block-comments
View
1  Changes
@@ -14,6 +14,7 @@ Revision history for Perl extension Module::Build.
- realclean might not delete Build.bat on Windows (RT#43863)
- include_dirs parameter now works correctly when given a single
string argument (RT#40177)
+ - Lots of spelling fixes in the POD (RT#45528)
Other
- On MSWin32, bumped File::Spec prereq to 3.30 for a variety of fixes
View
4 configs/darwin-Config.pm
@@ -891,7 +891,7 @@ sub FETCH {
} else {
$marker = "$_[1]=";
# return undef unless (($value) = $config_sh =~ m/^$_[1]='(.*)'\s*$/m);
- # Check for the common case, ' delimeted
+ # Check for the common case, ' delimited
$start = index($config_sh, "\n$marker$quote_type");
# If that failed, check for " delimited
if ($start == -1) {
@@ -1340,7 +1340,7 @@ the value is reset to a plain C<byacc> and is not useful.
From F<byteorder.U>:
This variable holds the byte order. In the following, larger digits
-indicate more significance. The variable byteorder is either 4321
+indicate more significance. The variable C<byteorder> is either 4321
on a big-endian machine, or 1234 on a little-endian, or 87654321
on a Cray ... or 3412 with weird order !
View
4 configs/win2k-Config.pm
@@ -927,7 +927,7 @@ sub FETCH {
} else {
$marker = "$_[1]=";
# return undef unless (($value) = $config_sh =~ m/^$_[1]='(.*)'\s*$/m);
- # Check for the common case, ' delimeted
+ # Check for the common case, ' delimited
$start = index($config_sh, "\n$marker$quote_type");
# If that failed, check for " delimited
if ($start == -1) {
@@ -1377,7 +1377,7 @@ the value is reset to a plain C<byacc> and is not useful.
From F<byteorder.U>:
This variable holds the byte order. In the following, larger digits
-indicate more significance. The variable byteorder is either 4321
+indicate more significance. The variable C<byteorder> is either 4321
on a big-endian machine, or 1234 on a little-endian, or 87654321
on a Cray ... or 3412 with weird order !
View
73 lib/Module/Build.pm
@@ -110,6 +110,11 @@ sub is_unixish { return ((os_type() || '') eq 'Unix') }
__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
@@ -233,7 +238,7 @@ The following build actions are provided by default.
If you run the C<Build> script without any arguments, it runs the
C<build> action, which in turn runs the C<code> and C<docs> actions.
-This is analogous to the MakeMaker 'make all' target.
+This is analogous to the C<MakeMaker> I<make all> target.
=item clean
@@ -247,7 +252,7 @@ C<_build/> directory and the C<Build> script itself).
[version 0.20]
-This action builds your codebase.
+This action builds your code base.
By default it just creates a C<blib/> directory and copies any C<.pm>
and C<.pod> files from your C<lib/> directory into the C<blib/>
@@ -328,7 +333,7 @@ This directory is what the distribution tarball is created from.
Creates the F<META.yml> file that describes the distribution.
-F<META.yml> is a file containing various bits of "metadata" about the
+F<META.yml> is a file containing various bits of I<metadata> 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<META.yml> in YAML format.
@@ -363,13 +368,13 @@ that directory.
[version 0.20]
-This will generate documentation (e.g. Unix man pages and html
+This will generate documentation (e.g. Unix man pages and HTML
documents) for any installable items under B<blib/> that
contain POD. If there are no C<bindoc> or C<libdoc> 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<binhtml> or C<libhtml> installation targets defined no action is
-taken for html documents.
+taken for HTML documents.
=item fakeinstall
@@ -476,7 +481,7 @@ installed on your system.
Build a PPD file for your distribution.
This action takes an optional argument C<codebase> which is used in
-the generated ppd file to specify the (usually relative) URL of the
+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.
@@ -489,7 +494,7 @@ Example:
[version 0.23]
Generates a PPM binary distribution and a PPD description file. This
-action also invokes the 'ppd' action, so it can accept the same
+action also invokes the C<ppd> action, so it can accept the same
C<codebase> argument described under that action.
This uses the same mechanism as the C<dist> action to tar & zip its
@@ -500,7 +505,7 @@ the result.
[version 0.32]
-This action prints out a Perl data structure of all prerequsites and the versions
+This action prints out a Perl data structure of all prerequisites and the versions
required. The output can be loaded again using C<eval()>. This can be useful for
external tools that wish to query a Build script for prerequisites.
@@ -594,7 +599,7 @@ or use a C<glob()>-style pattern:
=item testall
-[verion 0.2807]
+[version 0.2807]
[Note: the 'testall' action and the code snippets below are currently
in alpha stage, see
@@ -698,9 +703,9 @@ 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. --use-rcfile). Additionally, the argument to boolean options is
+(e.g. C<--use-rcfile>). Additionally, the argument to boolean options is
optional, and boolean options can be negated by prefixing them with
-'no' or 'no-' (e.g. --noverbose or --no-verbose).
+C<no> or C<no-> (e.g. C<--noverbose> or C<--no-verbose>).
=over 4
@@ -760,7 +765,7 @@ when you invoke C<perl Build.PL>.
--install_path html=/home/ken/docs/html
If you wish to locate your resource file in a different location, you
-can set the environment variable 'MODULEBUILDRC' to the complete
+can set the environment variable C<MODULEBUILDRC> to the complete
absolute path of the file containing your options.
@@ -789,7 +794,7 @@ Usually pure-Perl module files ending in F<.pm>.
=item arch
"Architecture-dependent" module files, usually produced by compiling
-XS, Inline, or similar code.
+XS, L<Inline>, or similar code.
=item script
@@ -817,11 +822,11 @@ pages belonging to the 'man3' category.
=item binhtml
-This is the same as C<bindoc> above, but applies to html documents.
+This is the same as C<bindoc> above, but applies to HTML documents.
=item libhtml
-This is the same as C<bindoc> above, but applies to html documents.
+This is the same as C<bindoc> above, but applies to HTML documents.
=back
@@ -851,7 +856,7 @@ parameter as follows:
binhtml => installhtml1dir installsitehtml1dir installvendorhtml1dir [*]
libhtml => installhtml3dir installsitehtml3dir installvendorhtml3dir [*]
- * Under some OS (eg. MSWin32) the destination for html documents is
+ * Under some OS (eg. MSWin32) the destination for HTML documents is
determined by the C<Config.pm> entry C<installhtmldir>.
The default value of C<installdirs> is "site". If you're creating
@@ -869,7 +874,7 @@ with perl itself (i.e. a "core module"), then you may set
C<installdirs> to "core" to overwrite the module in its present
location.
-(Note that the 'script' line is different from MakeMaker -
+(Note that the 'script' line is different from C<MakeMaker> -
unfortunately there's no such thing as "installsitescript" or
"installvendorscript" entry in C<Config.pm>, so we use the
"installsitebin" and "installvendorbin" entries to at least get the
@@ -904,7 +909,7 @@ system, you'll install as follows:
binhtml => /home/ken/html
libhtml => /home/ken/html
-Note that this is I<different> from how MakeMaker's C<PREFIX>
+Note that this is I<different> from how C<MakeMaker>'s C<PREFIX>
parameter works. C<install_base> just gives you a default layout under the
directory you specify, which may have little to do with the
C<installdirs=site> layout.
@@ -932,10 +937,10 @@ platform you're installing on.
=item prefix
-Provided for compatibility with ExtUtils::MakeMaker's PREFIX argument.
+Provided for compatibility with C<ExtUtils::MakeMaker>'s PREFIX argument.
C<prefix> should be used when you wish Module::Build to install your
modules, documentation and scripts in the same place
-ExtUtils::MakeMaker does.
+C<ExtUtils::MakeMaker> does.
The following are equivalent.
@@ -943,13 +948,13 @@ The following are equivalent.
perl Makefile.PL PREFIX=/tmp/foo
Because of the very complex nature of the prefixification logic, the
-behavior of PREFIX in MakeMaker has changed subtly over time.
+behavior of PREFIX in C<MakeMaker> has changed subtly over time.
Module::Build's --prefix logic is equivalent to the PREFIX logic found
-in ExtUtils::MakeMaker 6.30.
+in C<ExtUtils::MakeMaker> 6.30.
-If you do not need to retain compatibility with ExtUtils::MakeMaker or
-are starting a fresh Perl installation we recommand you use
-C<install_base> instead (and C<INSTALL_BASE> in ExtUtils::MakeMaker).
+If you do not need to retain compatibility with C<ExtUtils::MakeMaker> or
+are starting a fresh Perl installation we recommend you use
+C<install_base> instead (and C<INSTALL_BASE> in C<ExtUtils::MakeMaker>).
See L<Module::Build::Cookbook/Instaling in the same location as
ExtUtils::MakeMaker> for further information.
@@ -960,13 +965,13 @@ ExtUtils::MakeMaker> for further information.
=head1 MOTIVATIONS
There are several reasons I wanted to start over, and not just fix
-what I didn't like about MakeMaker:
+what I didn't like about C<MakeMaker>:
=over 4
=item *
-I don't like the core idea of MakeMaker, namely that C<make> should be
+I don't like the core idea of C<MakeMaker>, namely that C<make> should be
involved in the build process. Here are my reasons:
=over 4
@@ -991,25 +996,25 @@ build/install process to do what they want.
=item *
-There are several architectural decisions in MakeMaker that make it
+There are several architectural decisions in C<MakeMaker> that make it
very difficult to customize its behavior. For instance, when using
-MakeMaker you do C<use ExtUtils::MakeMaker>, but the object created in
+C<MakeMaker> you do C<use ExtUtils::MakeMaker>, but the object created in
C<WriteMakefile()> is actually blessed into a package name that's
created on the fly, so you can't simply subclass
C<ExtUtils::MakeMaker>. There is a workaround C<MY> package that lets
-you override certain MakeMaker methods, but only certain explicitly
-preselected (by MakeMaker) methods can be overridden. Also, the method
+you override certain C<MakeMaker> methods, but only certain explicitly
+preselected (by C<MakeMaker>) methods can be overridden. Also, the method
of customization is very crude: you have to modify a string containing
the Makefile text for the particular target. Since these strings
aren't documented, and I<can't> be documented (they take on different
values depending on the platform, version of perl, version of
-MakeMaker, etc.), you have no guarantee that your modifications will
-work on someone else's machine or after an upgrade of MakeMaker or
+C<MakeMaker>, etc.), you have no guarantee that your modifications will
+work on someone else's machine or after an upgrade of C<MakeMaker> or
perl.
=item *
-It is risky to make major changes to MakeMaker, since it does so many
+It is risky to make major changes to C<MakeMaker>, since it does so many
things, is so important, and generally works. C<Module::Build> is an
entirely separate package so that I can work on it all I want, without
worrying about backward compatibility.
View
43 lib/Module/Build/API.pod
@@ -2,6 +2,7 @@
Module::Build::API - API Reference for Module Authors
+=for :stopwords apache bsd distdir distsign gpl installdirs lgpl mit mozilla packlists
=head1 DESCRIPTION
@@ -151,7 +152,7 @@ for the details of how requirements can be specified.
[version 0.28]
If true, this parameter tells Module::Build to create a F<.packlist>
-file during the C<install> action, just like ExtUtils::MakeMaker does.
+file during the C<install> action, just like C<ExtUtils::MakeMaker> does.
The file is created in a subdirectory of the C<arch> installation
location. It is used by some other tools (CPAN, CPANPLUS, etc.) for
determining what files are part of an install.
@@ -196,9 +197,9 @@ that the C<license> parameter specifies a license that it knows about.
[version 0.19]
-This parameter lets you use Module::Build::Compat during the
+This parameter lets you use C<Module::Build::Compat> during the
C<distdir> (or C<dist>) action to automatically create a Makefile.PL
-for compatibility with ExtUtils::MakeMaker. The parameter's value
+for compatibility with C<ExtUtils::MakeMaker>. The parameter's value
should be one of the styles named in the L<Module::Build::Compat>
documentation.
@@ -211,7 +212,7 @@ file at the top level of your distribution. Currently it will simply
use C<Pod::Text> (or C<Pod::Readme> if it's installed) on the file
indicated by C<dist_version_from> and put the result in the F<README>
file. This is by no means the only recommended style for writing a
-README, but it seems to be one common one used on the CPAN.
+F<README>, but it seems to be one common one used on the CPAN.
If you generate a F<README> in this way, it's probably a good idea to
create a separate F<INSTALL> file if that information isn't in the
@@ -629,7 +630,7 @@ locations based on their package name, i.e. where they would be found
in a "normal" Module::Build-style distribution. This parameter is
mainly intended to support alternative layouts of files.
-For instance, if you have an old-style MakeMaker distribution for a
+For instance, if you have an old-style C<MakeMaker> distribution for a
module called C<Foo::Bar> and a F<Bar.pm> file at the top level of the
distribution, you could specify your layout in your C<Build.PL> like
this:
@@ -876,7 +877,7 @@ get or set on the build object.
print $build->pedantic, $/;
$build->pedantic(0);
-If the default value is a hash reference, this generetes a special-case
+If the default value is a hash reference, this generates a special-case
accessor method, wherein individual key/value pairs may be set or fetched:
print "stuff{foo} is: ", $build->stuff( 'foo' ), $/;
@@ -1171,7 +1172,7 @@ when the C<realclean> 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<eval()>-ed to obtain the authoritative
-set of prereqs, which might be different from the contents of
+set of prerequisites, which might be different from the contents of
F<META.yml> (because F<Build.PL> 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
@@ -1282,7 +1283,7 @@ Perl's C<system()>. It returns true or false to indicate success or
failure (the opposite of how C<system()> works, but more intuitive).
Note that if you supply a single argument to C<do_system()>, it
-will/may be processed by the systems's shell, and any special
+will/may be processed by the system's shell, and any special
characters will do their special things. If you supply multiple
arguments, no shell will get involved and the command will be executed
directly.
@@ -1346,14 +1347,14 @@ want to set the relative install path for custom build elements.
With no argument, it returns a reference to a hash containing all
elements and their respective values. This hash should not be modified
-directly; use the multi-argument below form to change values.
+directly; use the multiple argument below form to change values.
The single argument form returns the value associated with the
element C<$type>.
-The multi-argument form allows you to set the paths for element types.
-C<$value> must be a relative path using unix-like paths. (A series of
-directories seperated by slashes. Eg 'foo/bar'.) The return value is a
+The multiple argument form allows you to set the paths for element types.
+C<$value> must be a relative path using Unix-like paths. (A series of
+directories separated by slashes, e.g. C<foo/bar>.) The return value is a
localized path based on C<$value>.
Assigning the value C<undef> to an element causes it to be removed.
@@ -1384,12 +1385,12 @@ like C<install_base()>.
With no argument, it returns a reference to a hash containing all
elements and their respective values. This hash should not be modified
-directly; use the multi-argument below form to change values.
+directly; use the multiple argument below form to change values.
The single argument form returns the value associated with the
element C<$type>.
-The multi-argument form allows you to set the paths for element types.
+The multiple argument form allows you to set the paths for element types.
The supplied C<$path> should be an absolute path to install elements
of C<$type>. The return value is C<$path>.
@@ -1412,7 +1413,7 @@ exist.
This is the name of the original action invoked by the user. This
value is set when the user invokes F<Build.PL>, the F<Build> script,
-or programatically through the L<dispatch()|/"dispatch($action, %args)">
+or programmatically through the L<dispatch()|/"dispatch($action, %args)">
method. It does not change as sub-actions are executed as
dependencies are evaluated.
@@ -1432,7 +1433,7 @@ information about the build, and to share that information among
different entities involved in the build. See the example in the
C<current()> method.
-The C<notes()> method is essentally a glorified hash access. With no
+The C<notes()> method is essentially a glorified hash access. With no
arguments, C<notes()> returns the entire hash of notes. With one argument,
C<notes($key)> returns the value associated with the given key. With two
arguments, C<notes($key, $value)> sets the value associated with the given key
@@ -1506,9 +1507,9 @@ use the three-argument below form to change values.
The two argument form returns the value associated with the
element C<$type>.
-The multi-argument form allows you to set the paths for element types.
-C<$value> must be a relative path using unix-like paths. (A series of
-directories seperated by slashes. Eg 'foo/bar'.) The return value is a
+The multiple argument form allows you to set the paths for element types.
+C<$value> must be a relative path using Unix-like paths. (A series of
+directories separated by slashes, e.g. C<foo/bar>.) The return value is a
localized path based on C<$value>.
Assigning the value C<undef> to an element causes it to be removed.
@@ -1678,7 +1679,7 @@ call to C<new()>. This allows you to programmatically tell if C<perl Build.PL>
or any execution of C<./Build> had command line options specified that
override valid properties.
-The C<runtime_params()> method is essentally a glorified read-only hash. With
+The C<runtime_params()> method is essentially a glorified read-only hash. With
no arguments, C<runtime_params()> returns the entire hash of properties
specified on the command line. With one argument, C<runtime_params($key)>
returns the value associated with the given key.
@@ -1772,7 +1773,7 @@ See L<http://module-build.sourceforge.net/META-spec-current.html#keywords>.
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
+bug tracker, the repository location, a even subscription page for the
distribution mailing list.
See L<http://module-build.sourceforge.net/META-spec-current.html#resources>.
View
4 lib/Module/Build/Authoring.pod
@@ -100,7 +100,7 @@ Module::Build directly:
This is relatively straightforward, and is the best way to do things
if your My::Builder class contains lots of code. The
C<create_build_script()> method will ensure that the current value of
-C<@INC> (including the C</nonstandard/library/path>) is propogated to
+C<@INC> (including the C</nonstandard/library/path>) is propagated to
the Build script, so that My::Builder can be found when running build
actions.
@@ -281,7 +281,7 @@ C<Build> script.
Note that if you want to provide both a F<Makefile.PL> and a
F<Build.PL> for your distribution, you probably want to add the
-following to C<WriteMakefile> in your F<Makefile.PL> so that MakeMaker
+following to C<WriteMakefile> in your F<Makefile.PL> so that C<MakeMaker>
doesn't try to run your F<Build.PL> as a normal F<.PL> file:
PL_FILES => {},
View
22 lib/Module/Build/Base.pm
@@ -414,7 +414,7 @@ sub _perl_is_same {
}
}
-# Returns the absolute path of the perl interperter used to invoke
+# Returns the absolute path of the perl interpreter 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
# interpreter, on other it may contain a relative path, or simply
@@ -1075,11 +1075,11 @@ sub _pod_parse {
return $p->{$member} = $parser->$method();
}
-sub version_from_file { # Method provided for backwards compatability
+sub version_from_file { # Method provided for backwards compatibility
return Module::Build::ModuleInfo->new_from_file($_[1])->version();
}
-sub find_module_by_name { # Method provided for backwards compatability
+sub find_module_by_name { # Method provided for backwards compatibility
return Module::Build::ModuleInfo->find_module_by_name(@_[1,2]);
}
@@ -1701,7 +1701,7 @@ sub _read_arg {
}
}
-# decide whether or not an option requires/has an opterand
+# decide whether or not an option requires/has an operand
sub _optional_arg {
my $self = shift;
my $opt = shift;
@@ -1801,7 +1801,7 @@ sub read_args {
for my $subkey (keys %{$args{$key}}) {
next if !defined $args{$key}{$subkey};
my $subkey_ext = $self->_detildefy($args{$key}{$subkey});
- if ( $subkey eq 'html' ) { # translate for compatability
+ if ( $subkey eq 'html' ) { # translate for compatibility
$args{$key}{binhtml} = $subkey_ext;
$args{$key}{libhtml} = $subkey_ext;
} else {
@@ -3374,7 +3374,7 @@ sub _write_default_maniskip {
\B\.svn\b
\B\.cvsignore$
-# Avoid Makemaker generated and utility files.
+# Avoid MakeMaker generated and utility files.
\bMakefile$
\bblib
\bMakeMaker-\d
@@ -3382,7 +3382,7 @@ sub _write_default_maniskip {
\bblibdirs$
^MANIFEST\.SKIP$
-# Avoid VMS specific Makmaker generated files
+# Avoid VMS specific MakeMaker generated files
\bDescrip.MMS$
\bDESCRIP.MMS$
\bdescrip.mms$
@@ -3435,7 +3435,7 @@ sub ACTION_manifest {
ExtUtils::Manifest::mkmanifest();
}
-# Case insenstive regex for files
+# Case insensitive regex for files
sub file_qr {
return File::Spec->case_tolerant ? qr($_[0])i : qr($_[0]);
}
@@ -3782,7 +3782,7 @@ sub find_dist_packages {
my @pm_files = grep {exists $dist_files{$_}} keys %{ $self->find_pm_files };
# First, we enumerate all packages & versions,
- # seperating into primary & alternative candidates
+ # separating into primary & alternative candidates
my( %prime, %alt );
foreach my $file (@pm_files) {
next if $dist_files{$file} =~ m{^t/}; # Skip things in t/
@@ -3825,7 +3825,7 @@ sub find_dist_packages {
if ( $result->{err} ) {
# Use the selected primary package, but there are conflicting
- # errors amoung multiple alternative packages that need to be
+ # errors among multiple alternative packages that need to be
# reported
$self->log_warn(
"Found conflicting versions for package '$package'\n" .
@@ -3888,7 +3888,7 @@ sub find_dist_packages {
return \%prime;
}
-# seperate out some of the conflict resolution logic from
+# separate out some of the conflict resolution logic from
# $self->find_dist_packages(), above, into a helper function.
#
sub _resolve_module_versions {
View
61 lib/Module/Build/Compat.pm
@@ -398,6 +398,7 @@ sub _is_vms_mms {
1;
__END__
+=for :stopwords passthrough
=head1 NAME
@@ -417,15 +418,15 @@ Module::Build::Compat - Compatibility with ExtUtils::MakeMaker
=head1 DESCRIPTION
-Because ExtUtils::MakeMaker has been the standard way to distribute
+Because C<ExtUtils::MakeMaker> has been the standard way to distribute
modules for a long time, many tools (CPAN.pm, or your system
-administrator) may expect to find a working Makefile.PL in every
+administrator) may expect to find a working F<Makefile.PL> in every
distribution they download from CPAN. If you want to throw them a
-bone, you can use Module::Build::Compat to automatically generate a
-Makefile.PL for you, in one of several different styles.
+bone, you can use C<Module::Build::Compat> to automatically generate a
+F<Makefile.PL> for you, in one of several different styles.
-Module::Build::Compat also provides some code that helps out the
-Makefile.PL at runtime.
+C<Module::Build::Compat> also provides some code that helps out the
+F<Makefile.PL> at runtime.
=head1 METHODS
@@ -434,11 +435,11 @@ Makefile.PL at runtime.
=item create_makefile_pl($style, $build)
-Creates a Makefile.PL in the current directory in one of several
-styles, based on the supplied Module::Build object C<$build>. This is
+Creates a F<Makefile.PL> in the current directory in one of several
+styles, based on the supplied C<Module::Build> object C<$build>. This is
typically controlled by passing the desired style as the
-C<create_makefile_pl> parameter to Module::Build's C<new()> method;
-the Makefile.PL will then be automatically created during the
+C<create_makefile_pl> parameter to C<Module::Build>'s C<new()> method;
+the F<Makefile.PL> will then be automatically created during the
C<distdir> action.
The currently supported styles are:
@@ -447,37 +448,37 @@ The currently supported styles are:
=item small
-A small Makefile.PL will be created that passes all functionality
-through to the Build.PL script in the same directory. The user must
-already have Module::Build installed in order to use this, or else
+A small F<Makefile.PL> will be created that passes all functionality
+through to the F<Build.PL> script in the same directory. The user must
+already have C<Module::Build> installed in order to use this, or else
they'll get a module-not-found error.
=item passthrough
-This is just like the C<small> option above, but if Module::Build is
+This is just like the C<small> option above, but if C<Module::Build> is
not already installed on the user's system, the script will offer to
use C<CPAN.pm> to download it and install it before continuing with
the build.
=item traditional
-A Makefile.PL will be created in the "traditional" style, i.e. it will
+A F<Makefile.PL> will be created in the "traditional" style, i.e. it will
use C<ExtUtils::MakeMaker> and won't rely on C<Module::Build> at all.
-In order to create the Makefile.PL, we'll include the C<requires> and
+In order to create the F<Makefile.PL>, we'll include the C<requires> and
C<build_requires> dependencies as the C<PREREQ_PM> parameter.
You don't want to use this style if during the C<perl Build.PL> stage
you ask the user questions, or do some auto-sensing about the user's
-environment, or if you subclass Module::Build to do some
-customization, because the vanilla Makefile.PL won't do any of that.
+environment, or if you subclass C<Module::Build> to do some
+customization, because the vanilla F<Makefile.PL> won't do any of that.
=back
=item run_build_pl(args => \@ARGV)
-This method runs the Build.PL script, passing it any arguments the
+This method runs the F<Build.PL> script, passing it any arguments the
user may have supplied to the C<perl Makefile.PL> command. Because
-ExtUtils::MakeMaker and Module::Build accept different arguments, this
+C<ExtUtils::MakeMaker> and C<Module::Build> accept different arguments, this
method also performs some translation between the two.
C<run_build_pl()> accepts the following named parameters:
@@ -498,8 +499,8 @@ This is the filename of the script to run - it defaults to C<Build.PL>.
=item write_makefile()
-This method writes a 'dummy' Makefile that will pass all commands
-through to the corresponding Module::Build actions.
+This method writes a 'dummy' F<Makefile> that will pass all commands
+through to the corresponding C<Module::Build> actions.
C<write_makefile()> accepts the following named parameters:
@@ -522,10 +523,10 @@ So, some common scenarios are:
=item 1.
-Just include a Build.PL script (without a Makefile.PL
-script), and give installation directions in a README or INSTALL
+Just include a F<Build.PL> script (without a F<Makefile.PL>
+script), and give installation directions in a F<README> or F<INSTALL>
document explaining how to install the module. In particular, explain
-that the user must install Module::Build before installing your
+that the user must install C<Module::Build> before installing your
module.
Note that if you do this, you may make things easier for yourself, but
@@ -535,10 +536,10 @@ F<Makefile.PL>/C<ExtUtils::MakeMaker> way of doing things.
=item 2.
-Include a Build.PL script and a "traditional" Makefile.PL,
+Include a F<Build.PL> script and a "traditional" F<Makefile.PL>,
created either manually or with C<create_makefile_pl()>. Users won't
-ever have to install Module::Build if they use the Makefile.PL, but
-they won't get to take advantage of Module::Build's extra features
+ever have to install C<Module::Build> if they use the F<Makefile.PL>, but
+they won't get to take advantage of C<Module::Build>'s extra features
either.
For good measure, of course, test both the F<Makefile.PL> and the
@@ -546,8 +547,8 @@ F<Build.PL> before shipping.
=item 3.
-Include a Build.PL script and a "pass-through" Makefile.PL
-built using Module::Build::Compat. This will mean that people can
+Include a F<Build.PL> script and a "pass-through" F<Makefile.PL>
+built using C<Module::Build::Compat>. This will mean that people can
continue to use the "old" installation commands, and they may never
notice that it's actually doing something else behind the scenes. It
will also mean that your installation process is compatible with older
View
12 lib/Module/Build/Cookbook.pm
@@ -147,15 +147,15 @@ 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<INSTALL_BASE> in ExtUtils::MakeMaker 6.31 its easy to get them both
+C<INSTALL_BASE> in C<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
+installed and 6.31 of C<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.
+C<ExtUtils::MakeMaker> and C<Module::Build>.
MakeMaker Module::Build
PREFIX=... --prefix ...
@@ -168,7 +168,7 @@ ExtUtils::MakeMaker and Module::Build.
INC=... --extra_compiler_flags ...
POLLUTE=1 --extra_compiler_flags -DPERL_POLLUTE
-For example, if you are currently installing MakeMaker modules with
+For example, if you are currently installing C<MakeMaker> modules with
this command:
perl Makefile.PL PREFIX=~
@@ -190,7 +190,7 @@ Perl on the same machine. Because of this, it's difficult to document
where C<prefix> will place your modules.
In contrast, C<install_base> has predictable, easy to explain
-installation locations. Now that Module::Build and MakeMaker both
+installation locations. Now that C<Module::Build> and C<MakeMaker> both
have C<install_base> there is little reason to use C<prefix> other
than to preserve your existing installation locations. If you are
starting a fresh Perl installation we encourage you to use
@@ -381,7 +381,7 @@ John Peacock, author of the C<SVN-Notify-Mirror> distribution, says:
modules are available - SVN::Notify::Config and Net::SSH;
=item 2. If the S::N::Config module is loaded, I automatically
-generate testfiles for it during Build (using the C<PL_files>
+generate test files for it during Build (using the C<PL_files>
property).
=item 3. If the C<ssh_feature> is available, I ask if the user wishes
View
20 lib/Module/Build/ModuleInfo.pm
@@ -29,7 +29,7 @@ my $VARNAME_REGEXP = qr{ # match fully-qualified VERSION name
([\$*]) # sigil - $ or *
(
( # optional leading package name
- (?:::|\')? # possibly starting like just :: (ala $::VERSION)
+ (?:::|\')? # possibly starting like just :: (Ì la $::VERSION)
(?:\w+(?:::|\'))* # Foo::Bar:: ...
)?
VERSION
@@ -252,7 +252,7 @@ EOM
$vers{$pkg} = $v;
push( @pkgs, 'main' );
- # first non-comement line in undeclared packge defines package main
+ # first non-comment line in undeclared package defines package main
} elsif ( !exists($vers{main}) && $pkg eq 'main' && $line =~ /\w+/ ) {
$need_vers = 1;
$vers{main} = '';
@@ -371,9 +371,11 @@ sub pod {
__END__
+=for :stopwords ModuleInfo
+
=head1 NAME
-ModuleInfo - Gather package and POD information from a perl module files
+ModuleInfo - Gather package and POD information from a perl module file
=head1 DESCRIPTION
@@ -382,16 +384,16 @@ ModuleInfo - Gather package and POD information from a perl module files
=item new_from_file($filename, collect_pod => 1)
-Construct a ModuleInfo object given the path to a file. Takes an optional
-arguement C<collect_pod> which is a boolean that determines whether
+Construct a C<ModuleInfo> object given the path to a file. Takes an optional
+argument C<collect_pod> which is a boolean that determines whether
POD data is collected and stored for reference. POD data is not
collected by default. POD headings are always collected.
=item new_from_module($module, collect_pod => 1, inc => \@dirs)
-Construct a ModuleInfo object given a module or package name. In addition
+Construct a C<ModuleInfo> object given a module or package name. In addition
to accepting the C<collect_pod> argument as described above, this
-method accepts a C<inc> arguemnt which is a reference to an array of
+method accepts a C<inc> argument which is a reference to an array of
of directories to search for the module. If none are given, the
default is @INC.
@@ -432,7 +434,7 @@ Returns the POD data in the given section.
=item find_module_by_name($module, \@dirs)
Returns the path to a module given the module or package name. A list
-of directories can be passed in as an optional paramater, otherwise
+of directories can be passed in as an optional parameter, otherwise
@INC is searched.
Can be called as either an object or a class method.
@@ -441,7 +443,7 @@ Can be called as either an object or a class method.
Returns the entry in C<@dirs> (or C<@INC> by default) that contains
the module C<$module>. A list of directories can be passed in as an
-optional paramater, otherwise @INC is searched.
+optional parameter, otherwise @INC is searched.
Can be called as either an object or a class method.
View
2  lib/Module/Build/Platform/MacOS.pm
@@ -111,7 +111,7 @@ The sole purpose of this module is to inherit from
C<Module::Build::Base> and override a few methods. Please see
L<Module::Build> for the docs.
-=head2 Overriden Methods
+=head2 Overridden Methods
=over 4
View
2  lib/Module/Build/Platform/VMS.pm
@@ -357,7 +357,7 @@ sub _detildefy {
# Remove the tilde
$spec =~ s/^~//;
- # Remove any slash folloing the tilde if present.
+ # Remove any slash following the tilde if present.
$spec =~ s#^/##;
# break up the paths for the merge
View
4 lib/Module/Build/Platform/Windows.pm
@@ -43,7 +43,7 @@ sub ACTION_realclean {
my $full_progname = $0;
$full_progname =~ s/(?:\.bat)?$/.bat/i;
- # Vodoo required to have a batch file delete itself without error;
+ # Voodoo required to have a batch file delete itself without error;
# Syntax differs between 9x & NT: the later requires a null arg (???)
require Win32;
my $null_arg = (Win32::IsWinNT()) ? '""' : '';
@@ -90,7 +90,7 @@ sub make_executable {
}
# This routine was copied almost verbatim from the 'pl2bat' utility
-# distributed with perl. It requires too much vodoo with shell quoting
+# distributed with perl. It requires too much voodoo with shell quoting
# differences and shortcomings between the various flavors of Windows
# to reliably shell out
sub pl2bat {
View
2  lib/Module/Build/YAML.pm
@@ -141,7 +141,7 @@ Module::Build::YAML - Provides just enough YAML support so that Module::Build wo
Provides just enough YAML support so that Module::Build works even if YAML.pm is not installed.
-Currently, this amounts to the ability to write META.yml files when "perl Build distmeta"
+Currently, this amounts to the ability to write META.yml files when C<perl Build distmeta>
is executed via the Dump() and DumpFile() functions/methods.
=head1 AUTHOR
View
6 t/lib/DistGen.pm
@@ -278,8 +278,8 @@ sub regen {
if ( $opts{clean} ) {
$self->clean() if -d $dist_dirname;
} else {
- # TODO: This might leave dangling directories. Eg if the removed file
- # is 'lib/Simple/Simon.pm', The directory 'lib/Simple' will be left
+ # TODO: This might leave dangling directories; e.g. if the removed file
+ # is 'lib/Simple/Simon.pm', the directory 'lib/Simple' will be left
# even if there are no files left in it. However, clean() will remove it.
my @files = keys %{$self->{pending}{remove}};
foreach my $file ( @files ) {
@@ -598,7 +598,7 @@ Removes the entire distribution directory.
=head2 Editing Files
Note that C<$filename> should always be specified with unix-style paths,
-and are relative to the distribution root directory. Eg 'lib/Module.pm'
+and are relative to the distribution root directory, e.g. C<lib/Module.pm>.
No filesystem action is performed until the distribution is regenerated.
View
2  t/moduleinfo.t
@@ -54,7 +54,7 @@ my @modules = (
package Simple;
our $VERSION = '1.23';
---
- <<'---', # declared & defined on seperate lines with 'our'
+ <<'---', # declared & defined on separate lines with 'our'
package Simple;
our $VERSION;
$VERSION = '1.23';
Please sign in to comment.
Something went wrong with that request. Please try again.