Re: Bigger picture of automake variables

[Ralf Wildenhues]

Hello,

* LCID Fire wrote on Sun, Dec 14, 2008 at 01:58:48AM CET:
> I'm still pretty confused how the automake variables work. Perhaps
> someone could answer my questions.
> 1. I get it that they are just existing per Makfile in one directory.

Right.  Everything inside one Makefile.am typically only applies to this
Makefile.am.

However, there are certain things that are only sensible in the toplevel
Makefile.am, e.g., ACLOCAL_AMFLAGS.

> But what is then meant when the documentation talks about global
> variables? Does global mean they are predefined?

Unfortunately, I don't think the manual uses "global" in a consistent
way.  For example, it states that the command line argument '--foreign'
set the global strictness.  Here, that means it applies to the whole
package, thus all Makefile.am files, rather than only one of them.

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?

A patch to improve the sloppiness of the manual in this regard would be
appreciated.

> 2. When I actually add e.g. AC_SUBST([SOMETHING]) into a configure.in -
> what is the AC_SUBST doing?

Several things happen upon AC_SUBST:

- autoconf notices it, and emits code into configure so that
config.status will replace all instances of @SOMETHING@ with the value
of $SOMETHING in so-called config files: those files you register with
AC_CONFIG_FILES.  Typically, that includes all Makefile files, and maybe
some more.  (This is the file.in -> file step.)

- automake notices it, and emits a line
  SOMETHING = @SOMETHING@
into all Makefile.in files it generates.  (The next Automake release
will allow to prevent this step by adding an
AM_SUBST_NOTMAKE([SOMETHING]) to configure.ac.)

- autoconf will not warn about plain instances of SOMETHING in the
configure script, even if it would have before.  This is related to the
m4_pattern_{allow,forbid} mechanism, which tries to detect unexpanded
macro names by warning about words matchin AC_*, AM_* and similar (you
can use this in your own macros to warn about your prefixes, too, say
LCID_*).

> 3. Does the order of assigning variables make any difference?

Rarely.  The rules are pretty similar to those of 'make': things are
intended to be evaluated as late as possible.

> AM_CFLAGS = blub
> SUBDIRS = . somedir
> AM_CFLAGS = whatever

> Assuming that AM_CFLAGS is also accessible by the subdirectories, -
> would AM_CFLAGS have the value "blub" or "whatever"?

Variables are not transported between Makefile files the way you think.
In the above example, the first line is redundant, and AM_CFLAGS will
have the value of "whatever" in this Makefile.  In 'somedir', it will
have no particular value unless you set it there.

If you want some variable to be set to a certain value in all Makefiles,
then you can use AC_SUBST([AM_CFLAGS], ...) in configure.ac.
You can then still override it per-Makefile.am by adding
  AM_CFLAGS = ..

there.

Hope that helps.

Cheers,
Ralf