GNOME Bugzilla – Bug 108695
'autoheader' and 'autoreconf' fails
Last modified: 2004-12-22 21:47:04 UTC
autoconf's 'autoheader' fails because descriptions are missing in several AC_DEFINE statements. There should be an 'ACLOCAL_AMFLAGS' variable in the toplevel-Makefile.am; else 'autoreconf' is not working. The attached patch fixes these issues.
Created attachment 15103 [details] [review] Fix for issues with autoconf-2.57 and autoreconf
1. I wonder why this works with our autogen.sh. 2. Doesn't this normally produce warnings instead of errors? 3. These changes look good. The patch should be committed to both "branches", IF our autogen.sh works with if. Thanks.
1. It works with autogen.sh because 'autoheader' is commented out there ;) 2. It is an error: | $ autoheader | autoheader: missing template: GTKMM_DEBUG_REFCOUNTING | ... | $ echo $? | 1
Maybe we don't need to use autoheader. I said : " 3. These changes look good. The patch should be committed to both "branches", IF our autogen.sh works with if. Thanks. " So does our autogen.sh continue to work with these changes?
I do not see problems with autogen.sh; it runs without failures and 'make' succeeds also. My changes are affecting 'autoheader' and 'autoreconf' only.
Great. This should be applied to both branches, and glibmm too probably.
Applied to gtkmm 2.2, glibmm 2.4 and gtkmm 2.4. By the way, why do you want to use autoheader. What does it do that our autogen.sh does not? In general I think that autoreconf does not work with GNOME projects, because they do extra stuff such as intltoolize.
The main purpose of 'autoheader' is the documentation of the #defines at *one* place. Without 'autoheader' you will have to change two files (configure.in/*.m4 and acconfig.h) when modifying/adding a macroname. 'autogen.sh' tries to do the same like 'autoreconf' but has the following flaws: - There exists only one 'autoreconf' but a lot of 'autogen.sh' scripts with diffent options and/or semantics (e.g. some are calling ./configure, other ones do not). When employing or packaging new software it requires additional work to figure out what 'autogen.sh' is doing. - 'autoreconf' has more options than autogen.sh; e.g. 'autoreconf -i -f' can be used to recover from a broken build- environment. With 'autogen.sh' some tasks must be done manually. - 'autoreconf' supports the AUTO* environment variables selecting the used autotool version. Most 'autogen.sh' scripts are using static command names enforcing dirty tricks like copying/linking the tools to a certain place and manipulating the PATH. - 'autoreconf' is written and maintained by the authors of the auto* tools. I have seen a lot of 'autogen.sh' which are erroneously (e.g. '==' instead of '=' in tests, special assumptions about the development environment, tools are called in the wrong order). Therefore, I do not like the typical 'autogen.sh'. Additional tasks like calling 'intltoolize' do not conflict with 'autoreconf', e.g. you can still execute 'autoreconf && intltoolize'.
> The main purpose of 'autoheader' is the documentation of the > #defines at *one* place. Without 'autoheader' you will have to > change two files (configure.in/*.m4 and acconfig.h) But we have no acconfig.h > 'autogen.sh' tries to do the same like 'autoreconf' but has the > following flaws: [snip] > Additional tasks > like calling 'intltoolize' do not conflict with 'autoreconf', e.g. > you can still execute 'autoreconf && intltoolize'. I'm all for using autoreconf if it works. But I suggest that you try writing an autogen.sh for gnome-hello, that has something like autoreconf intltoolize inside. I think it will be more difficult than you think because the intltoolize (and/or maybe glib-gettextize) needs to be somewhere inside the autoreconf process. gtkmm isn't a good test of the theory because we don't have translated strings.
> But I suggest that you try writing an autogen.sh for gnome-hello, that > has something like autoreconf intltoolize inside. When fixing two issues (replacing AM_GLIB_GNU_GETTEXT with AM_GNU_GETTEXT([external]) and copying /usr/share/gettext/po/Makevars manually into po/) it is easy to generating such an autogen.sh: | autoreconf -i -f && intltoolize --force
This really is _not_ the place for this discussion, but I happen to be maintating gnome-hello now, so if you can send me a patch then I'll look at it and take it further.