[Top][All Lists]

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

Re: Bigger picture of automake variables

From: Ralf Wildenhues
Subject: Re: Bigger picture of automake variables
Date: Sun, 14 Dec 2008 10:17:52 +0100
User-agent: Mutt/1.5.18 (2008-05-17)


* 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 typically only applies to this

However, there are certain things that are only sensible in the toplevel, 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 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 (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

> 2. When I actually add e.g. AC_SUBST([SOMETHING]) into a -
> 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 step.)

- automake notices it, and emits a line
into all files it generates.  (The next Automake release
will allow to prevent this step by adding an

- 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

> 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
You can then still override it by adding
  AM_CFLAGS = ..


Hope that helps.


reply via email to

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