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.
