autoreconf doesn't obey ACLOCAL_PATH

[Ali Akcaagac]

Hello,

I would like to report this bug to you and try to explain the situation
in a more clear way with some examples. I am the author of CVSGnome a
buildscript for GNOME which I maintain for the past 5-6 years now.

http://www.akcaagac.com/
http://www.akcaagac.com/index_cvsgnome.html

Usually most projects offer an autogen.sh file where people run stuff
like aclocal, autoconf, automake and other things.

In the past months I've realized that more projects simply switched to
use autoreconf in their autogen.sh files but autoreconf doesn't obey the
ACLOCAL_PATH environment variable and thus fail to collect all aclocal
paths correctly.

Example (now independant to distributions)

My system installs autoconf, automake and other system related files
into prefix /usr

Now assuming someone wants to compile say GNOME or some stuff from fd.o
into a different prefix, say /opt/gnome or /usr/local or whatever.

Now you can imagine that some stuff from gnome installs further m4
macros in /usr/local/share/aclocal.

In former times people simply used to link the stuff found
in /usr/local/share/aclocal to /usr/share/aclocal and we know that this
simply looks wrong so people started to use ACLOCAL_PATH to collect
multiple aclocal paths together in the right row

So in case your autoconf, automake etc is in /usr, your m4 macros are
in /usr/share/aclocal. now to collect other directories together
from /usr/local you did something like

export ACLOCAL_PATH=-I /usr/local/share/aclocal

So when running aclocal, automake and autoconf get the paths correctly
and find the m4 macros. This was a good solution and worked for many
years. Now with the recent adoption of autorecong the variable
ACLOCAL_PATH is being ignored and paths from different prefixes can't be
found.

I'd like to explain this and would like to see a fix or a solution for
this issue so different aclocal paths can still be found when using
autoreconf.

- A.A.