Re: [PATCH 1/3] Replace 'automake' with @command{automake} where appropriate in automake.texi

[Ralf Wildenhues]

Hi William,

* William Pursell wrote on Mon, Dec 01, 2008 at 10:06:10PM CET:
> The bare 'automake' occurs often in automake.texi where
> it should be @command{automake}.  There is some inconsistency,
> however, in that often 'Automake' is used, and I am unsure
> if it is appropriate to change such instances to @command{automake},
> so am leaving them untouched.

I think this can be improved a bit further.  The manual is intended to
use Automake when referring to the package, and @command{automake} when
referring to the program that can be executed.  When in doubt, I think
Automake should be preferred.

For example:

> @@ -3159,9 +3159,9 @@ directories, in this order:
>
>  @table @code
>  @item @var{acdir-APIVERSION}
> -This is where the @file{.m4} macros distributed with automake itself
> -are stored.  @var{APIVERSION} depends on the automake release used;
> -for automake 1.6.x, @var{APIVERSION} = @code{1.6}.
> +This is where the @file{.m4} macros distributed with @command{automake} 
> itself

This should be `Automake'.

> +are stored.  @var{APIVERSION} depends on the @command{automake} release used;

Likewise.

> +for @command{automake} 1.6.x, @var{APIVERSION} = @code{1.6}.
>
>  @item @var{acdir}
>  This directory is intended for third party @file{.m4} files, and is

> @@ -3195,7 +3195,7 @@ drops the @var{APIVERSION} directory.  For example, if 
> one specifies
>  @end enumerate
>
>  This option, @option{--acdir}, is intended for use by the internal
> -automake test suite only; it is not ordinarily needed by end-users.
> address@hidden test suite only; it is not ordinarily needed by end-users.

Likewise.

> @@ -3250,7 +3250,7 @@ If the @address@hidden option is used, then 
> @command{aclocal}
>  will search for the @file{dirlist} file in @var{dir}.  In the
>  @samp{--acdir=/opt/private/} example above, @command{aclocal} would look
>  for @file{/opt/private/dirlist}.  Again, however, the @option{--acdir}
> -option is intended for use by the internal automake test suite only;
> +option is intended for use by the internal @command{automake} test suite 
> only;

Likewise.

> @@ -3812,7 +3812,7 @@ choose the assembler for you (by default the C 
> compiler) and set
>  @acindex AM_PROG_CC_C_O
>  @acindex AC_PROG_CC_C_O
>  This is like @code{AC_PROG_CC_C_O}, but it generates its results in
> -the manner required by automake.  You must use this instead of
> +the manner required by @command{automake}.  You must use this instead of

Not sure about this one either.

>  @code{AC_PROG_CC_C_O} when you need this functionality, that is, when
>  using per-target flags or subdir-objects with C sources.
>

> @@ -3957,7 +3957,7 @@ skip this section!
>  @itemx AM_DEP_TRACK
>  @itemx AM_OUTPUT_DEPENDENCY_COMMANDS
>  These macros are used to implement Automake's automatic dependency
> -tracking scheme.  They are called automatically by automake when
> +tracking scheme.  They are called automatically by @command{automake} when

Technically, it's not the program that calls them, but some of the m4
macros cause them to be invoked.  Not sure here.

>  required, and there should be no need to invoke them manually.


> @@ -11677,7 +11677,7 @@ A major and long-awaited release, that comes more 
> than two years after
>  @item The new dependency tracking scheme that uses @command{depcomp}.
>  Aside from the improvement on the dependency tracking itself
>  (@pxref{Dependency Tracking Evolution}), this also streamlines the use
> -of automake generated @file{Makefile.in}s as the @file{Makefile.in}s
> +of @command{automake} generated @file{Makefile.in}s as the 
> @file{Makefile.in}s

I have a question here: shouldn't this be address@hidden'
here?  With hyphenation, in German I tend to have a good feeling about
when it's needed and when not, but I'm not quite sure whether those
rules (which I probably can't even formulate precisely) carry over to
English writing.

>  used during development are now the same as those used in
>  distributions.  Before that the @file{Makefile.in}s generated for
>  maintainers required GNU @command{make} and GCC, they were different

> @@ -12039,7 +12039,7 @@ Java.)  This problem is easy to fix, by modifying 
> dependency
>  generators to record every probe, instead of every successful open.
>
>  @item
> -Since automake generates dependencies as a side effect of compilation,
> +Since @command{automake} generates dependencies as a side effect of 
> compilation,

I think I'd prefer Automake here.

>  there is a bootstrapping problem when header files are generated by
>  running a program.  The problem is that, the first time the build is
>  done, there is no way by default to know that the headers are

Cheers,
Ralf