[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] documentation errors

From: William Pursell
Subject: [PATCH] documentation errors
Date: Sun, 23 Nov 2008 17:18:47 +0000
User-agent: Thunderbird (Macintosh/20081105)


here's another set of corrections to the documentation.
There was a question I had that I notated by adding
comments to the .texi file which appears in the patch
below re: AM_PROG_CC_C_O.  The documentation claims
that one must invoke AM_PROG_CC_C_O in order to use
program_CFLAGS, but I have succesfully used program_CFLAGS
and have never used AM_PROG_CC_C_O, so I believe
this is out of date.

commit 3a31de76f19c0db0645faaa2388b26bf85c5989d
Author: William Pursell <address@hidden>
Date:   Sun Nov 23 17:01:22 2008 +0000

    Typos thru 8.7

diff --git a/ChangeLog b/ChangeLog
index 20e3bae..bd9c156 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2008-11-23  William Pursell  <address@hidden>
+       * doc/automake.texi (Macro search path, Extending aclocal)
+       (Local Macros, Serials, Public macros, Directories)
+       (Conditional Subdirectories, Nesting Packages)
+       (Building a program, Libtool Modules)
+       (Program and Library Variables, Default _SOURCES, LIBOBJS):
+       Mostly correcting verb/object tense agreement  (ie:
+       "Here is a case that illustrate" s/illustrate/illustrates/),
+       some word swaps ("need just" becomes "just need"), and
+       general trivial cleanup.
 2008-11-22  William Pursell  <address@hidden>
            Ralf Wildenhues  <address@hidden>

diff --git a/doc/automake.texi b/doc/automake.texi
index e131d25..b98ef90 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -3292,7 +3292,7 @@ using it to work around local system-dependent tool 

 Similarly, @file{dirlist} can be handy if you have installed a local
-copy Automake on your account and want @command{aclocal} to look for
+copy of Automake in your account and want @command{aclocal} to look for
 macros installed at other places on the system.

@@ -3380,7 +3380,7 @@ do not require it.
 If you have been directed here by the @command{aclocal} diagnostic but
 are not the maintainer of the implicated macro, you will want to
 contact the maintainer of that macro.  Please make sure you have the
-last version of the macro and that the problem already hasn't been
+latest version of the macro and that the problem hasn't already been
 reported before doing so: people tend to work faster when they aren't
 flooded by mails.

@@ -3429,7 +3429,7 @@ the place where Gettext's macros should be installed.  So 
even if you
 do not really care about the rebuild rules, you should define

-When @samp{aclocal -I m4} is run, it will build a @file{aclocal.m4}
+When @samp{aclocal -I m4} is run, it will build an @file{aclocal.m4}
 that @code{m4_include}s any file from @file{m4/} that defines a
 required macro.  Macros not found locally will still be searched in
 system-wide directories, as explained in @ref{Macro search path}.
@@ -3528,7 +3528,7 @@ Normally these serial numbers are completely ignored by
 However when using @command{aclocal}'s @option{--install} feature, these
 serial numbers will modify the way @command{aclocal} selects the
 macros to install in the package: if two files with the same basename
-exists in your search path, and if at least one of them use a
+exist in your search path, and if at least one of them uses a
 @samp{#serial} line, @command{aclocal} will ignore the file that has
 the older @samp{#serial} line (or the file that has none).

@@ -3536,7 +3536,7 @@ Note that a serial number applies to a whole M4 file, not 
to any macro
 it contains.  A file can contains multiple macros, but only one

-Here is a use case that illustrate the use of @option{--install} and
+Here is a use case that illustrates the use of @option{--install} and
 its interaction with serial numbers.  Let's assume we maintain a
 package called MyPackage, the @file{} of which requires a
 third-party macro @code{AX_THIRD_PARTY} defined in
@@ -3662,7 +3662,7 @@ For instance, it could enforce the @file{m4/}-style 
layout discussed in

 We have no idea when and how this will happen.  This has been
 discussed several times in the past, but someone still has to commit
-itself to that non-trivial task.
+to that non-trivial task.

 From the user point of view, @command{aclocal}'s removal might turn
 out to be painful.  There is a simple precaution that you may take to
@@ -3718,7 +3718,7 @@ Automake ships with several Autoconf macros that you can 
use from your
 This is used when a ``multilib'' library is being built.  The first
 optional argument is the name of the @file{Makefile} being generated; it
-defaults to @samp{Makefile}.  The second option argument is used to find
+defaults to @samp{Makefile}.  The second optional argument is used to find
 the top source directory; it defaults to the empty string (generally
 this should not be used unless you are familiar with the internals).
@@ -3982,14 +3982,14 @@ from @code{AM_INIT_AUTOMAKE}.
 @node Directories
 @chapter Directories

-For simple projects that distributes all files in the same directory
+For simple projects that distribute all files in the same directory
 it is enough to have a single @file{} that builds
 everything in place.

 In larger projects it is common to organize files in different
 directories, in a tree.  For instance one directory per program, per
 library or per module.  The traditional approach is to build these
-subdirectory recursively: each directory contains its @file{Makefile}
+subdirectories recursively: each directory contains its @file{Makefile}
 (generated from @file{}), and when @command{make} is run
 from the top level directory it enters each subdirectory in turn to
 build its contents.
@@ -4114,7 +4114,7 @@ conditionally so that some directory will be omitted from 
the build.
 directories, even those that have been conditionally left out of the
 build.  Recall our example where we may not want to build subdirectory
 @file{opt/}, but yet we want to distribute it?  This is where
address@hidden come into play: @samp{opt} may not appear in
address@hidden comes into play: @samp{opt} may not appear in
 @code{SUBDIRS}, but it must appear in @code{DIST_SUBDIRS}.

 Precisely, @code{DIST_SUBDIRS} is used by @samp{make
@@ -4123,7 +4123,7 @@ other recursive rules use @code{SUBDIRS}.

 If @code{SUBDIRS} is defined conditionally using Automake
 conditionals, Automake will define @code{DIST_SUBDIRS} automatically
-from the possibles values of @code{SUBDIRS} in all conditions.
+from the possible values of @code{SUBDIRS} in all conditions.

 If @code{SUBDIRS} contains @code{AC_SUBST} variables,
 @code{DIST_SUBDIRS} will not be defined correctly because Automake
@@ -4208,7 +4208,7 @@ values of @code{MAYBE_OPT} are, it is necessary to define
 @subsection Non-configured Subdirectories
 @cindex Subdirectories, configured conditionally

-The semantic of @code{DIST_SUBDIRS} is often misunderstood by some
+The semantics of @code{DIST_SUBDIRS} are often misunderstood by some
 users that try to @emph{configure and build} subdirectories
 conditionally.  Here by configuring we mean creating the
 @file{Makefile} (it might also involve running a nested
@@ -4243,7 +4243,7 @@ I.e., the @file{Makefile} must exists or the recursive 
 rules will not be able to process the directory.
 @item Any configured directory must be listed in @code{DIST_SUBDIRS}.

-So that the cleaning rule remove the generated @file{Makefile}s.
+So that the cleaning rules remove the generated @file{Makefile}s.
 It would be correct to see @code{DIST_SUBDIRS} as a variable that
 lists all the directories that have been configured.
 @end itemize
@@ -4274,7 +4274,7 @@ name of a directory appears in @code{SUBDIRS} or 
 directory has been omitted.  One way to avoid this check is to use the
 @code{AC_SUBST} method to declare conditional directories; since
 @command{automake} does not know the values of @code{AC_SUBST}
-variables it cannot ensure the corresponding directory exist.
+variables it cannot ensure the corresponding directory exists.

 @node Alternative
 @section An Alternative Approach to Subdirectories
@@ -4357,7 +4357,7 @@ an otherwise equivalent set of variables without 
@samp{nobase_} prefix.

 In the GNU Build System, packages can be nested to arbitrary depth.
-This means that a package can embedded other packages with their own
+This means that a package can embed other packages with their own
 @file{configure}, @file{Makefile}s, etc.

 These other packages should just appear as subdirectories of their
@@ -4495,7 +4495,7 @@ programs.  Most of the comments about these also apply to 
 * Program Sources::             Defining program sources
 * Linking::                     Linking with libraries or extra objects
 * Conditional Sources::         Handling conditional sources
-* Conditional Programs::        Building program conditionally
+* Conditional Programs::        Building a program conditionally
 @end menu

 @node Program Sources
@@ -4856,7 +4856,7 @@ variable (@pxref{Program and Library Variables}).
 @cindex Empty libraries
 Be careful when selecting library components conditionally.  Because
 building an empty library is not portable, you should ensure that any
-library contains always at least one object.
+library always contains at least one object.

 To use a static library when building a program, add it to
 @code{LDADD} for this program.  In the following example, the program
@@ -5032,7 +5032,7 @@ Here is an example where @code{WANTEDLIBS} is an 
 variable set at @file{./configure}-time to either @file{},
 @file{}, both, or none.  Although @samp{$(WANTEDLIBS)}
 appears in the @code{lib_LTLIBRARIES}, Automake cannot guess it
-relates to @file{} or @file{} by the time it creates
+relates to @file{} or @file{} at the time it creates
 the link rule for these two libraries.  Therefore the @option{-rpath}
 argument must be explicitly supplied.

@@ -5207,10 +5207,10 @@ mymodule_la_SOURCES = doit.c
 mymodule_la_LDFLAGS = -module
 @end example

-Ordinarily, Automake requires that a library's name starts with
+Ordinarily, Automake requires that a library's name start with
 @code{lib}.  However, when building a dynamically loadable module you
 might wish to use a "nonstandard" name.  Automake will not complain
-about such nonstandard name if it knows the library being built is a
+about such nonstandard names if it knows the library being built is a
 libtool module, i.e., if @option{-module} explicitly appears in the
 library's @code{_LDFLAGS} variable (or in the common @code{AM_LDFLAGS}
 variable when no per-library @code{_LDFLAGS} variable is defined).
@@ -5258,7 +5258,7 @@ If @address@hidden is not defined, the global

 These flags are passed to libtool after the @address@hidden
 option computed by Automake (if any), so
address@hidden@var{library}_LIBTOOLFLAGS} (or @code{AM_LIBTOOLFLAGS}) is the
address@hidden@var{library}_LIBTOOLFLAGS} (or @code{AM_LIBTOOLFLAGS}) is a
 good place to override or supplement the @address@hidden

@@ -5378,7 +5378,7 @@ the issue.
 @node Program and Library Variables
 @section Program and Library Variables

-Associated with each program are a collection of variables that can be
+Associated with each program is a collection of variables that can be
 used to modify how that program is built.  There is a similar list of
 such variables for each library.  The canonical name of the program (or
 library) is used as a base for naming these variables.
@@ -5505,7 +5505,7 @@ the compiler or linker flags).  @xref{Libtool Flags}.
 It is also occasionally useful to have a target (program or library)
 depend on some other file that is not actually part of that target.
 This can be done using the @code{_DEPENDENCIES} variable.  Each
-targets depends on the contents of such a variable, but no further
+target depends on the contents of such a variable, but no further
 interpretation is done.

 Since these dependencies are associated to the link rule used to
@@ -5582,6 +5582,9 @@ object file will be named, for instance, 
@file{maude-sample.o}.  (See
 also @ref{renamed objects}.)  The use of per-target compilation flags
 with C sources requires that the macro @code{AM_PROG_CC_C_O} be called
 from @file{}.
address@hidden Is this still true?  I have projects
address@hidden that use per-target flags and I've never used it, nor
address@hidden seen a warning of any kind.

 In compilations with per-target flags, the ordinary @samp{AM_} form of
 the flags variable is @emph{not} automatically included in the
@@ -5652,12 +5655,12 @@ would be built from @file{sub_libc___a.c}, i.e., the 
default source
 was the canonized name of the target, with @file{.c} appended.
 We believe the new behavior is more sensible, but for backward
 compatibility automake will use the old name if a file or a rule
-with that name exist and @code{AM_DEFAULT_SOURCE_EXT} is not used.)
+with that name exists and @code{AM_DEFAULT_SOURCE_EXT} is not used.)

 @cindex @code{check_PROGRAMS} example
 @vindex check_PROGRAMS
 Default sources are mainly useful in test suites, when building many
-tests programs each from a single source.  For instance, in
+test programs each from a single source.  For instance, in

 check_PROGRAMS = test1 test2 test3
@@ -5672,7 +5675,7 @@ Without the last line, they will be built from 

 @cindex Libtool modules, default source example
 @cindex default source, Libtool modules example
-Another case where is this convenient is building many Libtool modules
+Another case where this is convenient is building many Libtool modules
 (@address@hidden), each defined in its own file

@@ -5686,7 +5689,7 @@ lib_LTLIBRARIES =
 Finally, there is one situation where this default source computation
 needs to be avoided: when a target should not be built from sources.
 We already saw such an example in @ref{true}; this happens when all
-the constituents of a target have already been compiled and need just
+the constituents of a target have already been compiled and just need
 to be combined using a @code{_LDADD} variable.  Then it is necessary
 to define an empty @code{_SOURCES} variable, so that automake does not
 compute a default.
@@ -5782,7 +5785,7 @@ libcompat_a_LIBADD = $(LIBOBJS) $(ALLOCA)

 The library can have any name, of course, and anyway it is not going
 to be installed: it just holds the replacement versions of the missing
-or broken functions so we can later link them in.  In many projects
+or broken functions so we can later link them in.  Many projects
 also include extra functions, specific to the project, in that
 library: they are simply added on the @code{_SOURCES} line.

William Pursell

reply via email to

[Prev in Thread] Current Thread [Next in Thread]