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