[Top][All Lists]

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

ACLOCAL best practice

From: Ryan Lortie
Subject: ACLOCAL best practice
Date: Sat, 13 Nov 2010 11:49:57 -0500


We use ACLOCAL_FLAGS in the GNOME project to specify the include
directories for when we are installing into unusual prefixes.

For example, say I have a GNOME setup in /home/desrt/local.

If I install glib, it includes "gsettings.m4" which gets installed
into /home/desrt/local/share/aclocal/.  So my ACLOCAL_FLAGS contains

  ACLOCAL_FLAGS="-I /home/desrt/local/share/aclocal"

and all GNOME packages pick this up (usually by explicit referencing of
this variable from our and

(for example)


I recently filed a bug against a component because it
didn't honour the ACLOCAL_FLAGS environment variable.  That bug got
closed, telling me to use ACLOCAL like so:

  ACLOCAL='aclocal -I /home/desrt/local/share/aclocal"

which makes a lot of sense and is actually nicer, since the autotools
themselves pick this up.

The problem with this approach is that some of our modules explicitly
invoke a particular version of automake.  Consider for example that we
have automake 1.11 as the default (as installed in /usr/bin/automake)
but a project wants to run automake-1.9 from it's script.

At the same time, this project would want to run ${ACLOCAL} in order to
ensure that it picked up the proper include path from that environment
variable -- which would get it aclocal-1.11 (via /usr/bin/aclocal).

What is the best practice here?

In my opinion, this is an argument for why ACLOCAL_FLAGS (or at least
some ACLOCAL_PATH) environment variable is a good idea; anything that
avoids also specifying the name of the binary at the same time.  I think
this ought to be supported in an official way within the autotools.  I'm
willing to write a patch if people believe it to be a good idea.


reply via email to

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