GNOME Bugzilla – Bug 134207
GNOME_COMMON_INIT() is broken for rebuilds
Last modified: 2004-12-22 21:47:04 UTC
I've been seeing this issue for a while, but never bothered to track it down. If I check certain modules out of CVS, build them, subsequent runs of "make" may fail if a "cvs update" updates the configure.in file. This seems to be due to brain damage in GNOME_COMMON_INIT() In the following examples, assume that ACLOCAL_FLAGS is set to "-I /prefix/share/aclocal", and gnome-common installed its macros into /prefix/share/aclocal/gnome2-macros. On the initial build, things go something like this: 1. user calls the package's autogen.sh script 2. autogen.sh script calls /prefix/bin/gnome-autogen.sh 3. gnome-autogen.sh adds "-I /prefix/share/aclocal/gnome2-macros" to ACLOCAL_FLAGS so that Gnome macros can be found. 4. gnome-autogen.sh calls /prefix/share/aclocal/gnome2-macros/autogen.sh 5. .../autogen.sh calls all the build tools, then the package's configure script. 6. The configure script calls the GNOME_COMMON_INIT() macro 7. The GNOME_COMMON_INIT changes the definition of ACLOCAL to "$ACLOCAL $ACLOCAL_FLAGS", so that if aclocal would be invoked later on, it will find all the macros again. Unfortunately, this causes problems on subsequent rebuilds. If configure gets rerun on a subsequent build (because one of its prereqs changed), ACLOCAL_FLAGS won't include /prefix/share/aclocal/gnome2-macros. This means that the next time aclocal gets run, it won't find the Gnome macros and cause a build failure. There is some code in GNOME_COMMON_INIT() that tries to fix this by using AC_CACHE_VAL() to record some values on the first run of configure and use it on subsequent runs. Unfortunately, this stopped working when autoconf-2.50 was released, and caching was turned off by default ... The best fix I can think of is the following (I mentioned these in a message to Malcolm): * move the Gnome macros into the real aclocal dir * install the gnome autogen.sh script as /prefix/bin/gnome-autogen.sh * define GNOME_COMMON_INIT as the following: AC_DEFUN([GNOME_COMMON_INIT], [AM_ACLOCAL_FLAGS='${ACLOCAL_FLAGS}' AC_SUBST([AM_ACLOCAL_FLAGS])]) (this will work fine for automake >= 1.5. We might need to do something else to support 1.4). This is probably 2.7 material at this point ...
All of this makes sense, except that it would probably be better just to make GNOME_COMMON_INIT a no-op and if people really want AM_ACLOCAL_FLAGS they can do it themselves. I cannot see where we are using it anywhere substantial (the gstreamer guys need those tricks, but they obviously don't use our macros). In any case, there is no way I am touching this until after 2.6 is released. With less than four weeks to release, breaking the build at this low level would make me even more unpopular than normal.
[Above, I meant ACLOCAL_AMFLAGS, rather than AM_ACLOCAL_FLAGS] Well, if you don't do anything, $ACLOCAL_FLAGS won't get passed to aclocal on a rebuild. Here is the rebuild rule for aclocal.m4, as generated by automake-1.8: ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 am__aclocal_m4_deps = $(top_srcdir)/configure.in $(ACLOCAL_M4): $(am__aclocal_m4_deps) cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS) without something setting ACLOCAL_AMFLAGS, no arguments get passed to $(ACLOCAL).
More info: libgnomeprint and libgnomeprintui fail every rebuild. It doesn't call GNOME_COMMON_INIT, but instead just AC_SUBST's ACLOCAL_AMFLAGS to $ACLOCAL_FLAGS. I suppose it is just broken though ...
What do packages outside of GNOME do, then? Is automake so brain-damaged that everybody has to manually AC_SUBST() the same thing all the time? Or is there some more automatic way to make it happen?
There is no standard way of altering the aclocal path. Automake >= 1.5 added a makefile variable ACLOCAL_AMFLAGS that it will pass to aclocal when the makefile calls it, but that is it. From what I can tell, ACLOCAL_AMFLAGS is supposed to be set from the toplevel Makefile.am, or as an AC_SUBST() variable. It seems that if you do both, the setting in the makefile wins, so it should be pretty safe to use (we just need a way to handle automake 1.4). You mentioned killing GNOME_COMMON_INIT altogether, which doesn't sound that bad. The alternative is to get each package to add a line like the following to their toplevel Makefile.am: ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) And for packages still using automake-1.4: ACLOCAL = @ACLOCAL@ $(ACLOCAL_FLAGS)
I might have a go at doing a patch for this and testing it out. If we are moving the macros to $datadir/aclocal, it might be worth taking the opportunity to trim the list slightly. In particular, I'd like to remove gnome-deprecated-macros.m4 and curses.m4. I removed the last few uses of the deprecated macros in the devel platform, and as far as I can tell, only gnome-utils uses curses.m4. I'll talk to Glynn about gnome-utils. It will be good to get rid of some of the magic in gnome-common ...
Created attachment 27657 [details] [review] no-gnome1-macros.patch Initial patch. Does the following: - don't build bin/ and macros/ directories. - install gnome-common.m4 and compiler-flags.m4 into $(datadir)/aclocal - install macros2/autogen.sh as $(bindir)/gnome-autogen.sh Todo: - get gnome-utils to use an internal copy of curses.m4. - maybe rename compiler-flags.m4 to gnome-compiler-flags.m4 to reduce chance of conflicts? - maybe rename macros2/autogen.sh to gnome-autogen.sh to simplify makefile rules? Once this has been tested a bit, it would probably be worth posting about this to desktop-devel-list.
Looks like I was wrong about gnome-utils -- It already includes the contents of curses.m4 in its acinclude.m4 file, so isn't actually using curses.m4. So not installing curses.m4 doesn't break gnome-utils.
Created attachment 27665 [details] [review] no-gnome1-macros.patch v2 This version includes changes to the GNOME_COMMON_INIT macro. It simply sets ACLOCAL_AMFLAGS to "\${ACLOCAL_FLAGS}" and AC_SUBST()'s it. On rebuilds, aclocal will be called with the current contents of $ACLOCAL_FLAGS as arguments.
Been testing this for the last few days without any problems so far. It turns out that gnome-utils doesn't even use the curses check macro. So as well as not needing the copy from gnome-common, it doesn't need the copy from its acinclude.m4 file. I think it can be quite safely killed off. While going through the code in autogen.sh, I wonder whether the code that modifies ACLOCAL_FLAGS, PATH and LD_LIBRARY_PATH based on GNOME2_DIR/GNOME2_PATH should be removed. It would cause the same rebuild issues as the ones in the existing gnome-autogen.sh wrappert script mentioned in the initial comment. Setting those variables in "autogen" is only going to affect the results of configure tests -- those values won't be seen during the "make" or "make install" phases. Since the user is pretty much required to set up ACLOCAL_FLAGS, PATH and LD_LIBRARY_PATH anyway, is there any benefit to that code?
Relevant desktop-devel-list discussion at: http://mail.gnome.org/archives/desktop-devel-list/2004-May/msg00239.html
OK, here are my thoughts: I am completely in favour of the patch and the ideas behind it. Thanks for doing all this work. I'm going to think a bit more about whether to remove the ACLOCAL_FLAGS modifying stuff you talk about in comment #10. A while back somebody from Novell sent me a bug report about that; the bug was sorted out in a different way in the end, but I want to just get clear in my head that we are not throwing away something that people are using there. I agree that PATH and LD_LIBRARY_PATH are a bit pointless to set, though. If you have confidence in your patch (by which I mean a clean rebuild of GNOME works, which I assume is what you are doing in your testing), then feel free to check it in. Just try not to break anything valuable. :-)
Okay. I've checked a modified version of the patch into CVS now (I did the file renamings that I mentioned in a previous comment). There was no negative feedback, and other packages build as before. As far as the ACLOCAL_FLAGS/PATH/LD_LIBRARY_PATH, it seems quite clear that it will cause problems for some people. By having a different environment while configure is run compared to when make is run, the following problems could occur: 1. a configure check finds a program in the PATH, so passes. When make is run, the program can no longer be found, so configure fails. 2. a configure check searching for a library might successfully compile, link and run a test program. During make, similar operations might fail due to directories missing from LD_LIBRARY_PATH. 3. If configure.in changes after a build, on the rebuild, aclocal will be called without the extra flags, and may fail. If people are relying on the behaviour, then they will probably find that rebuilds break. Furthermore, there are a number of core Gnome modules that don't use the gnome-common autogen script, so they would break if $GNOME2_PATH/share/aclocal wasn't already in ACLOCAL_FLAGS. Of course, this doesn't show that no one is relying on the current autogen.sh behaviour w.r.t. GNOME2_PATH (just that they'd be silly to do so :). I guess I'll ask on the mailing list about it.
Closing this bug too, since I got rid of the GNOME2_PATH stuff.