Ralf Wildenhues wrote: > [ moving from automake@ ] > > Hello, > > * LCID Fire wrote on Sun, Dec 14, 2008 at 07:51:07PM CET: >> Ralf Wildenhues wrote: >>> Elsewhere, flags like AM_LDFLAGS are denoted as global. In that case, >>> it is meant to say that, unlike program_LDFLAGS, which applies to >>> 'program' only, the flags apply to all binaries created by this >>> Makefile.am (that themselves don't have per-target flags which override >>> the "global" AM_LDFLAGS). Makes sense a bit? >> IMO global is used incorrectly here because it is just per Makefile. >> Global initially made me think it really is for all Makefiles. > > Good point. WDYT about the patch below? Definitely much better than before. I have some proposes though.
> Can I get a real name for THANKS? LCID Fire or Andreas Bergmeier - whatever you like >> So basically variables are not ever transported between Makefiles. > Correct. Is this written down somewhere on the docs? > Well, what really happens is that, with > AC_SUBST([VARIABLE]) > > in configure.ac, and > VARIABLE = my value from Makefile.am > > in Makefile.am, the Makefile.in will contain > > VARIABLE = @VARIABLE@ > ... > VARIABLE = my value from Makefile.am > > and thus the latter wins. I think this is a candidate for the docs. > >>> Hope that helps. >> Thanks, helped a great deal. These concepts were not really obvious to >> me when reading the documentation. > > Good documentation patches are always welcome. :-) Make the docs a wiki and I'll be eager to update the docs :) > Do not use 'global' for makefile-wide settings. > > * doc/automake.texi (Linking, Libtool Flags) > (Program and Library Variables, Flag Variables Ordering): > Reword instances of `global variables' that really mean > makefile-wide ones. > Report by LCID Fire <[email protected]>. > > diff --git a/doc/automake.texi b/doc/automake.texi > index fa0a277..e7ae93b 100644 > --- a/doc/automake.texi > +++ b/doc/automake.texi > @@ -4586,9 +4586,8 @@ Sometimes, multiple programs are built in one directory > but do not share > the same link-time requirements. In this case, you can use the > @co...@var{prog}_ldadd} variable (where @var{prog} is the name of the > program as it appears in some @code{_PROGRAMS} variable, and usually > -written in lowercase) to override the global @code{LDADD}. If this > -variable exists for a given program, then that program is not linked > -using @code{LDADD}. > +written in lowercase) to override @code{LDADD}. If this variable exists > +for a given program, then that program is not linked using @code{LDADD}. > @vindex maude_LDADD > > For instance, in GNU cpio, @code{pax}, @code{cpio} and @code{mt} are > @@ -5256,8 +5255,8 @@ Libtool Manual} for more options) should appear before > the mode > selection on the command line; in @file{Makefile.am}s they should > be listed in the @sa...@var{library}_libtoolflags} variable. > > -If @sa...@var{library}_libtoolflags} is not defined, the global > -...@code{am_libtoolflags} variable is used instead. > +If @sa...@var{library}_libtoolflags} is not defined, then the variable > +...@code{am_libtoolflags} is used instead. > > These flags are passed to libtool after the @option{--t...@var{tag}} > option computed by Automake (if any), so > @@ -5495,11 +5494,11 @@ of any library built by your package. Doing so will > ensure that > > @item maude_LDFLAGS > This variable is used to pass extra flags to the link step of a program > -or a shared library. It overrides the global @code{AM_LDFLAGS} variable. > +or a shared library. It overrides the @code{AM_LDFLAGS} variable. > > @item maude_LIBTOOLFLAGS > This variable is used to pass extra options to @command{libtool}. > -It overrides the global @code{AM_LIBTOOLFLAGS} variable. > +It overrides the @code{AM_LIBTOOLFLAGS} variable. > These options are output before @command{libtool}'s > @option{--mo...@var{mode}} > option, so they should not be mode-specific options (those belong to > the compiler or linker flags). @xref{Libtool Flags}. > @@ -10768,7 +10767,7 @@ has neither @code{AM_} nor per-target cousin. > Finally you should not think either that the existence of a per-target > variable implies that of an @code{AM_} variable or that of a user > variable. For instance, the @code{mumble_LDADD} per-target variable > -overrides the global @code{LDADD} variable (which is not a user > +overrides the makefile-wide @code{LDADD} variable (which is not a user > variable), and @code{mumble_LIBADD} exists only as a per-target > variable. @xref{Program and Library Variables}. -Finally you should not think either that the existence of a per-target -variable implies that of an @code{AM_} variable or that of a user +Finally you should not think that the existence of a per-target +variable implies the existance of an @code{AM_} variable or of a user variable. For instance, the @code{mumble_LDADD} per-target variable -overrides the global @code{LDADD} variable (which is not a user +overrides the makefile-wide @code{LDADD} variable (which is not a user variable), and @code{mumble_LIBADD} exists only as a per-target variable. @xref{Program and Library Variables}.
