[Module-build-checkins] Module-Build/lib/Module Build.pm,1.191,1.192

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/module-build/Module-Build/lib/Module
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15497/lib/Module

Modified Files:
	Build.pm 
Log Message:
Document the C<invoked_action()> accessor, and clarify the behavior of C<current_action()>.

Spellcheck PODs & standardize to two spaces between sentences.


Index: Build.pm
===================================================================
RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build.pm,v
retrieving revision 1.191
retrieving revision 1.192
diff -u -d -r1.191 -r1.192

--- Build.pm	31 Oct 2005 03:57:59 -0000	1.191
+++ Build.pm	1 Nov 2005 09:58:37 -0000	1.192
@@ -159,7 +159,7 @@
 There are some general principles at work here.  First, each task when
 building a module is called an "action".  These actions are listed
 above; they correspond to the building, testing, installing,
-packaging, etc. tasks.
+packaging, etc., tasks.
 
 Second, arguments are processed in a very systematic way.  Arguments
 are always key=value pairs.  They may be specified at C<perl Build.PL>
@@ -167,7 +167,7 @@
 their values last for the lifetime of the C<Build> script.  They may
 also be specified when executing a particular action (i.e.
 C<Build test verbose=1>), in which case their values last only for the
-lifetime of that command.  Per-action command-line parameters take
+lifetime of that command.  Per-action command line parameters take
 precedence over parameters specified at C<perl Build.PL> time.
 
 The build process also relies heavily on the C<Config.pm> module, and
@@ -267,7 +267,7 @@
 =item distcheck
 
 Reports which files are in the build directory but not in the
-F<MANIFEST> file, and vice versa. (See L<manifest> for details)
+F<MANIFEST> file, and vice versa.  (See L<manifest> for details.)
 
 =item distclean
 
@@ -311,7 +311,7 @@
 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
+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.
 
@@ -334,7 +334,7 @@
 =item html
 
 This will generate HTML documentation for any binary or library files
-under B<blib/> that contain POD. The HTML documentation will only be
+under B<blib/> that contain POD.  The HTML documentation will only be
 installed if the install paths can be determined from values in
 C<Config.pm>.  You can also supply or override install paths on the
 command line by specifying C<install_path> values for the C<binhtml>
@@ -343,7 +343,7 @@
 =item install
 
 This action will use C<ExtUtils::Install> to install the files from
-C<blib/> into the system. See L<How Installation Paths are Determined>
+C<blib/> into the system.  See L<How Installation Paths are Determined>
 for details about how Module::Build determines where to install
 things, and how to influence this process.
 
@@ -386,8 +386,8 @@
 =item manpages
 
 This will generate man pages for any binary or library files under
-B<blib/> that contain POD. The man pages will only be installed if the
-install paths can be determined from values in C<Config.pm>. You can
+B<blib/> that contain POD.  The man pages will only be installed if the
+install paths can be determined from values in C<Config.pm>.  You can
 also supply or override install paths by specifying there values on
 the command line with the C<bindoc> and C<libdoc> installation
 targets.
@@ -398,7 +398,7 @@
 
 This action takes an optional argument C<codebase> which is used in
 the generated ppd file to specify the (usually relative) URL of the
-distribution. By default, this value is the distribution name without
+distribution.  By default, this value is the distribution name without
 any path information.
 
 Example:
@@ -486,7 +486,7 @@
 =item testpod
 
 This checks all the files described in the C<docs> action and 
-produces C<Test::Harness>-style output. If you are a module author,
+produces C<Test::Harness>-style output.  If you are a module author,
 this is useful to run before creating a new release.
 
 =item versioninstall
@@ -497,7 +497,7 @@
 
 If you have the C<only.pm> module installed on your system, you can
 use this action to install a module into the version-specific library
-trees. This means that you can have several versions of the same
+trees.  This means that you can have several versions of the same
 module installed and C<use> a specific one like this:
 
  use only MyModule => 0.55;
@@ -518,15 +518,15 @@
 =back
 
 
-=head2 General Commandline Options
+=head2 General Command Line Options
 
-The following options can be used during any invokation of Build.PL or
+The following options can be used during any invocation of Build.PL or
 the Build script, during any action.
 
 NOTE: There is some preliminary support for options to use the more
-familiar long option style. Most options can be preceeded with the
+familiar long option style.  Most options can be preceded with the
 C<--> long option prefix, and the underscores changed to dashes
-(e.g. --ignore-prereqs). Additionally, the argument to boolean options
+(e.g. --ignore-prereqs).  Additionally, the argument to boolean options
 is optional (e.g. --verbose), and boolean options can be negated by
 prefixing them with 'no' or 'no-' (e.g. --noverbose or --no-verbose).
 
@@ -553,7 +553,7 @@
 
 =item use_rcfile
 
-Load the F<~/.modulebuildrc> option file. This option can be set to
+Load the F<~/.modulebuildrc> option file.  This option can be set to
 false to prevent the custom resource file from being loaded.
 
 =item verbose
@@ -563,20 +563,20 @@
 =back
 
 
-=head2 Default Commandline Options (F<.modulebuildrc>)
+=head2 Default Command Line Options (F<.modulebuildrc>)
 
 When Module::Build starts up, it will look for a file,
-F<$ENV{HOME}/.modulebuildrc>. If the file exists, the options
+F<$ENV{HOME}/.modulebuildrc>.  If the file exists, the options
 specified there will be used as defaults, as if they were typed on the
-command line. The defaults can be overridden by specifying new values
+command line.  The defaults can be overridden by specifying new values
 on the command line.
 
 The action name must come at the beginning of the line, followed by any
-amount of whitespace and then the options. Options are given the same
-as they would be on the commandline. They can be separated by any
+amount of whitespace and then the options.  Options are given the same
+as they would be on the command line.  They can be separated by any
 amount of whitespace, including newlines, as long there is whitespace at
-the beginning of each continued line. Anything following a hash mark (C<#>)
-is considered a comment, and is stripped before parsing. If more than
+the beginning of each continued line.  Anything following a hash mark (C<#>)
+is considered a comment, and is stripped before parsing.  If more than
 one line begins with the same action name, those lines are merged into
 one set of options.
 
@@ -827,9 +827,10 @@
 Many systems have Perl configs that make little sense with PREFIX.
 For example, OS X, where core modules go in
 F</System/Library/Perl/...>, user-installed modules go in
-F</Library/Perl/...>, and man pages go in F</usr/share/man/...>.  The PREFIX is thus set to F</>.
-Install L<Foo::Bar> on OS X with C<PREFIX=/home/spurkis> and you get
-things like F</home/spurkis/Library/Perl/5.8.1/Foo/Bar.pm> and
+F</Library/Perl/...>, and man pages go in F</usr/share/man/...>.  The
+PREFIX is thus set to F</>.  Install L<Foo::Bar> on OS X with
+C<PREFIX=/home/spurkis> and you get things like
+F</home/spurkis/Library/Perl/5.8.1/Foo/Bar.pm> and
 F</home/spurkis/usr/share/man/man3/Foo::Bar.3pm>.  Not too pretty.
 
 The problem is not limited to Unix-like platforms, either - on Windows
@@ -869,7 +870,7 @@
 =head2 PREFIX will be supported
 
 The current maintainer of MakeMaker has offered to implement C<PREFIX>
-pass-through support in Module::Build B<for backwards compatability
+pass-through support in Module::Build B<for backwards compatibility
 only>.  You are still strongly recommended to use C<install_base>.
 
 =head1 MOTIVATIONS



