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

Re: ACLOCAL best practice

[Stefano Lattarini]

On Saturday 13 November 2010, Ryan Lortie wrote:
> Hello,
Hello Ryan.

Just a quick partial reply ...

> [CUT]
> In my opinion, this is an argument for why ACLOCAL_FLAGS
> (or at least some ACLOCAL_PATH environment variable)
Supporting ACLOCAL_PATH is a good idea IMO -- and the nice thing about it is
that there's already a patch (currently under reviewed) implementing it:
 
It will probably be included in the next automake version (1.12).

> 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.
If ACLOCAL_PATH is enough for your needs, that shouldn't be necessary,
since someone else has alredy done the work (kudos to Paolo Bonzini).

HTH,
  Stefano

Re: ACLOCAL best practice

[Ralf Wildenhues]

Hello Ryan,

* Ryan Lortie wrote on Sat, Nov 13, 2010 at 05:49:57PM CET:
> 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"

To add to Stefano's reply, the above also has the disadvantage that the
first -I argument is special to aclocal --install, see
  info Automake 'aclocal Options'

Cheers,
Ralf