ACLOCAL best practice

[Ryan Lortie]

Hello,

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 autogen.sh and Makefile.am).

(for example)
  $ACLOCAL $ACLOCAL_FLAGS || exit $?

and
  ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}

I recently filed a bug against a freedesktop.org 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 autogen.sh 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.

Cheers