GNOME Bugzilla – Bug 590064
Set ACLOCAL as well as ACLOCAL_FLAGS
Last modified: 2014-03-13 14:13:09 UTC
autoreconf (and some non-GNOME autogen.sh scripts) don't honour ACLOCAL_FLAGS, only ACLOCAL. I made my tree set both these vars at all times, since the worst that can happen is a needlessly long command line (which I find much better than a configure script which fails halfway through :). I also considered a force_autoreconf option but I remembered gnome-autogen.sh does stuff autoreconf doesn't, like gettextize .. :( Is this worth committing into the main tree? Some packages (Pixman, at least) have autogen scripts that chain to autoreconf, so ACLOCAL_FLAGS actually isn't being honoured there at all - but Pixman's configure script only needs pkg.m4 so on a normal system it doesn't matter. On Windows of course it's another story :) Thanks!
Created attachment 139424 [details] [review] patch to set ACLOCAL as well as ACLOCAL_FLAGS
I didn't review the behaviour yet, but the patch has several unrelated hunks (the first one about use_autoreconf for example); could it be cleaned?
Created attachment 139427 [details] [review] patch to set ACLOCAL as well as ACLOCAL_FLAGS but not suck sorry, i even looked through it closely :( clean patch fail
Sorry I have then been busy and I couldn't review it immediately. I have now been looking at it and I don't like it much, setting two different variables when addpath() is called really looks wrong. As the problem seems to be with autoreconf, I'd much prefer an ACLOCAL variable was crafted only when calling autoreconf. I have now pushed a patch that does exactly this. commit 0d58c65887bb779b054b564eaa5764dc56d719fd Author: Frédéric Péters <fpeters@0d.be> Date: Sat Aug 8 12:03:44 2009 +0200 [autotools] craft ACLOCAL and pass it to autoreconf autoreconf doesn't honour ACLOCAL_FLAGS, so we craft an ACLOCAL environment variable and pass it to autoreconf when called. (GNOME bug 590064)
IMHO it's a bug in the packages themselves, not jhbuild. Per http://www.gnu.org/software/autoconf/manual/html_node/autoreconf-Invocation.html they should set ACLOCAL_AMFLAGS in the (toplevel) Makefile.am to pass extra flags to aclocal when autoreconfing.
I agree with Christian. Even with the current hack in jhbuild, it will still break if aclocal is invoked from the Makefile instead. It is not particularly intuitive, but there is an easy way to make it all work, by putting this in a project's top-level Makefile.am: ACLOCAL_AMFLAGS = -I macros ${ACLOCAL_FLAGS} The curly braces are important. Autoreconf extracts the value from Makefile.am and evaluates it in a shell context, so it will fail if round parentheses are used. Doing it this way makes it work for both autoreconf and automatic invocation of aclocal from the Makefile.
There is still build issues when the project uses autoreconf inside autogen.sh, it fails to detect libtool (jhbuild using the system one). Jhbuild currently crafts an ACLOCAL with ACLOCAL_FLAGS for autogen_sh == "autoreconf" case only. perhaps it should do it in all cases? (In reply to comment #6) > I agree with Christian. Even with the current hack in jhbuild, it will still > break if aclocal is invoked from the Makefile instead. It is not particularly > intuitive, but there is an easy way to make it all work, by putting this in a > project's top-level Makefile.am: > > ACLOCAL_AMFLAGS = -I macros ${ACLOCAL_FLAGS} While I understand this is a possible solution, I find it quite intrusive, as this is a project file, defining project specific flags. Using the environment variable is a system or user responsibility, and I don't think it's worth going changing each and every package to honor it, but rather the tool making use of it. In fact, the proper fix is probably in autoreconf of aclocal itself. reopening
I only have a basic knowledge of the autotools, but isn't the solution ACLOCAL_PATH? ACLOCAL_PATH is available in automake 1.11.2. See bug 634617.
(In reply to comment #8) > I only have a basic knowledge of the autotools, but isn't the solution > ACLOCAL_PATH? ACLOCAL_PATH is available in automake 1.11.2. See bug 634617. Oh, I didn't realize there was a a new variable. With the new automake/aclocal >1.11.2, it takes ACLOCAL_PATH into account. So autoreconf will work if it set to include system paths. However, for some reasons, it doesn't. ACLOCAL_FLAGS=-I /opt/gnome/share/aclocal -I /usr/local/share/aclocal -I /usr/share/aclocal ACLOCAL_PATH=/opt/gnome/share/aclocal So autoreconf still fails (to find libtool, and other macros etc..)
*** This bug has been marked as a duplicate of bug 634617 ***