Re: [PATCH 1/3] Replace 'automake' with @command{automake} where appropriate in automake.texi
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.
> [EMAIL PROTECTED] test suite only; it is not ordinarily needed by end-users.
Likewise.
> @@ -3250,7 +3250,7 @@ If the @[EMAIL PROTECTED] 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 [EMAIL PROTECTED]'
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
Re: [PATCH 3/3] Simple typographical and grammar errors in automake.texi.
Hi William,
* William Pursell wrote on Mon, Dec 01, 2008 at 10:06:32PM CET:
> Fix object/article consistency (eg "an flag" becomes "a flag"),
> correct minor punctuation errors, etc.
Thanks! Pushed with a couple of minor changes, as below.
> @@ -7839,7 +7839,7 @@ suppress the base name step. For example:
> nobase_include_HEADERS = stdio.h sys/types.h
> @end example
>
> -Will install @file{stdio.h} in @samp{$(includedir)} and @file{types.h}
> +will install @file{stdio.h} in @samp{$(includedir)} and @file{types.h}
> in @samp{$(includedir)/sys}.
I added a @noindent here. More generally, there are probably several
@example's in the manual where the following text belongs right to it,
but there is no @noindent keeping them together, which looks a bit ugly
in the info output.
> -Note that Automake does not make any difference between rules with
> +Note that Automake does not make any distinction between rules with
> commands and rules that only specify dependencies.
"No distinction without a difference!" :-)
(good phrase to memorize the difference between the two words)
FWIW, I squashed in this change to avoid an underfull hbox:
@@ -8927,7 +8927,7 @@ suffixes in the @code{SUFFIXES} variable @strong{before} y
implicit rule.
For instance, the following definition prevents Automake from misinterpreting
[EMAIL PROTECTED]:} as an attempt to transform @file{.idlC} files into
+the @samp{.idlC.cpp:} rule as an attempt to transform @file{.idlC} files into
@file{.cpp} files.
@example
> @@ -9923,15 +9923,15 @@ happen. CVS's timestamp handling can also let you
> think an
> out-of-date file is up-to-date.
>
> For instance, suppose a developer has modified @file{Makefile.am} and
> -has rebuilt @file{Makefile.in}. He then decide to do a last-minute
> +has rebuilt @file{Makefile.in}. He then decides to do a last-minute
> change to @file{Makefile.am} right before checking in both files
> (without rebuilding @file{Makefile.in} to account for the change).
>
> -This last change to @file{Makefile.am} make the copy of
> +This last change to @file{Makefile.am} makes the copy of
> @file{Makefile.in} out-of-date. Since CVS processes files
> -alphabetically, when another developer @samp{cvs update} his or her
> +alphabetically, when another developer @samp{cvs update}s his or her
I happen to dislike quoted text with unquoted postfixes a bit; maybe
this should be reformulated as
when another developer uses @samp{cvs update} to update his or her
tree
Hmm. Or maybe not; dunno.
> tree, @file{Makefile.in} will happen to be newer than
> [EMAIL PROTECTED] This other developer will not see
> [EMAIL PROTECTED] This other developer will not see that
> @file{Makefile.in} is out-of-date.
> @@ -10013,13 +10013,13 @@ the build continue is one of the arguments of the
> @cindex @code{AM_MAINTAINER_MODE}, purpose
> @acindex AM_MAINTAINER_MODE
>
> [EMAIL PROTECTED] allows to choose whether the so called
> [EMAIL PROTECTED] allows you to choose whether the so called
> "rebuild rules" should be enabled or disabled. With
> @code{AM_MAINTAINER_MODE([enable])}, they are enabled by default,
> otherwise they are disabled by default. In the latter case, if
> you have @code{AM_MAINTAINER_MODE} in @file{configure.ac}, and run
> @samp{./configure && make}, then @command{make} will *never* attempt to
> -rebuilt @file{configure}, @file{Makefile.in}s, Lex or Yacc outputs, etc.
> +rebuild @file{configure}, @file{Makefile.in}s, Lex or Yacc outputs, etc.
This could be: @file{Makefile.in} files
> I.e., this disables build rules for files that are usually distributed
> and that users should normally not have to update.
> @@ -11067,7 +11067,7 @@ The @code{AM_PATH_PYTHON} macro uses similar commands
> to define
>
> Of course not all tools are as advanced as Python regarding that
> substitution of @var{prefix}. So another strategy is to figure the
> -part of the of the installation directory that must be preserved. For
> +part of the installation directory that must be preserved. For
Oh! Vim is good at detecting doubled words like `the the', but it
doesn't detect doubled pairs yet. That should be fixed.
Cheers,
Ralf
Re: [PATCH 2/3] Replace 'configure' with '@command{configure}' as appropriate.
Hi William, * William Pursell wrote on Mon, Dec 01, 2008 at 10:06:18PM CET: > > There are several occurences of the phrase 'at configure time' > where it may be appropriate to make this change as well, but > it is not clear to me that doing so is correct and I'm > applying the principal of minimal change. (aka laziness). This is good, I pushed it. Thanks! Ralf
Re: magic variables for included fragments
Hi Akim,
* Akim Demaille wrote on Wed, Dec 03, 2008 at 02:58:22PM CET:
> > * Ralf Wildenhues wrote on Sun, Oct 12, 2008 at 10:46:06PM CEST:
> >>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Sorry I did not answer before.
No problem of course.
In the meantime I did come up with some patch for "fixed"
include fragment.mk
that does sane recursive inclusion, but with backward compatibility
warnings, but said patch still has a bug. I hope to be able to fix
it soon.
> In other projects I'm involved in we store in candidates/ branches
> that contain patches under discussion. That makes it easier to try,
> experiment etc.
>
> Could you please push this somewhere? Thanks!
Yes, of course. I will try to clean all this up and push it, hopefully
sometime this weekend.
> > @@ -9151,6 +9169,70 @@ condition applies to the entire contents of that
> fragment.
> > Makefile fragments included this way are always distributed because
> > they are needed to rebuild @file{Makefile.in}.
>
> > [EMAIL PROTECTED] $(AM_SUBDIR)
> > [EMAIL PROTECTED] $(AM_PREFIX)
> > [EMAIL PROTECTED] $(AM_CANON)
> > [EMAIL PROTECTED] $(AM_REVERSE)
>
> This is really excellent news, it will vastly simplify some Makefiles.
> It will also solve a problem I have found several times: if you share
> some directories in different projects (typically using svn externals
> or git sub modules), then it is basically impossible to put them at
> different places in the packages: they should always be at a fixed
> path from the top of the package.
Indeed.
> Otherwise too many things go wrong
> (especially the creation of .deps btw: automake does garbage if you
> include a local.mk which defines foo_SOURCES = $(prefix)/foo.cc: it
> creates '$(prefix)/.deps', and I really mean single quotes: the very
> string '$(prefix)' not interpolated (which it can't, of course)).
Yep. :-/
A while ago (I'm sure it's been more than a couple of years now),
ventured at changing depout.m4 to lift this limitation. I did have
something working back then, but it required invoking `make' at
config.status time. I dropped this idea as being unsuitable in the
presence of bugs (e.g., if `make' reinvokes configure, then there
can be an endless loop). Maybe I should go back and look again,
for example writing out a separate makefile could help...
> I confess that I like that facets of a single thing keep a common root
> in the names: AM_SUB_REL, AM_SUB_PREFIX, AM_SUB_CANON, AM_SUB_REV or
> something. But of course concision does matter.
I agree with you on both accounts. I am torn between these choices as
well. If somebody has better ideas, they are welcome!
Cheers,
Ralf
Re: magic variables for included fragments
>>> "RW" == Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Ralf Wildenhues wrote on Sun, Oct 12, 2008 at 10:46:06PM CEST:
>>
>> I'll follow up on automake-patches with a patch to test.
> Here we go. WDYT?
Hi Ralf,
Sorry I did not answer before.
In other projects I'm involved in we store in candidates/ branches
that contain patches under discussion. That makes it easier to try,
experiment etc.
Could you please push this somewhere? Thanks!
> @@ -9151,6 +9169,70 @@ condition applies to the entire contents of that
> fragment.
> Makefile fragments included this way are always distributed because
> they are needed to rebuild @file{Makefile.in}.
> [EMAIL PROTECTED] $(AM_SUBDIR)
> [EMAIL PROTECTED] $(AM_PREFIX)
> [EMAIL PROTECTED] $(AM_CANON)
> [EMAIL PROTECTED] $(AM_REVERSE)
This is really excellent news, it will vastly simplify some Makefiles.
It will also solve a problem I have found several times: if you share
some directories in different projects (typically using svn externals
or git sub modules), then it is basically impossible to put them at
different places in the packages: they should always be at a fixed
path from the top of the package. Otherwise too many things go wrong
(especially the creation of .deps btw: automake does garbage if you
include a local.mk which defines foo_SOURCES = $(prefix)/foo.cc: it
creates '$(prefix)/.deps', and I really mean single quotes: the very
string '$(prefix)' not interpolated (which it can't, of course)).
I confess that I like that facets of a single thing keep a common root
in the names: AM_SUB_REL, AM_SUB_PREFIX, AM_SUB_CANON, AM_SUB_REV or
something. But of course concision does matter.
> [EMAIL PROTECTED]
> +bin_PROGRAMS += $(AM_PREFIX)foo
> +$(AM_CANON)foo_SOURCES = $(AM_PREFIX)foo.c $(AM_PREFIX)foo.h
> +$(AM_CANON)foo_CPPFLAGS = -I$(AM_SUBDIR) -I$(AM_PREFIX)include
> [EMAIL PROTECTED] example
Great!
