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

.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

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

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 !
 

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 !
 

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,24 +937,24 @@ 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.
 
     perl Build.PL --prefix /tmp/foo
     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.