GNOME Bugzilla – Bug 633208
Use autoreconf instead gnome-autogen.sh
Last modified: 2010-11-15 18:14:26 UTC
Created attachment 173277 [details] [review] Use autoreconf instead gnome-autogen.sh We can drop gnome-autogen.sh completely and use the upstream tool (autoreconf) instead
I'd take if you add error handling for missing gtkdocize and missing autoreconf.
Created attachment 173329 [details] [review] Use autoreconf instead gnome-autogen.sh. Second aproach Updated patch with error handling
Feel free to push. I'd add double-quotes around $srcdir more generously.
Comment on attachment 173329 [details] [review] Use autoreconf instead gnome-autogen.sh. Second aproach committed with your comments. commit c06264ae25218dd72a70bf5eb93d552f2763f9aa
After this change, compiling pango I got this error: libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. acinclude.m4:68: the serial number must appear before any macro definition configure.in:96: installing `./config.guess' configure.in:96: installing `./config.sub' configure.in:55: installing `./install-sh' configure.in:55: installing `./missing' gtk-doc.make:7: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL docs/Makefile.am:99: `gtk-doc.make' included from here The same that you can find on build.gnome.org: http://build.gnome.org/builders/pango-bxlug-sid/builds/1122/steps/pango%20build/logs/stdio It is required something extra in order to work?
One problem with autoreconf is that it ignores $ACLOCAL_FLAGS. gnome-autogen.sh on the other hand uses $ACLOCAL_FLAGS. So to keep things working smoothly for people that have their m4 stuff in non-standard locations the new autogen.sh should export ACLOCAL="aclocal $ACLOCAL_FLAGS" when running autoreconf. (Of course, once one understands what is happening, it is equally trivial for people who come across that to do it themselves in their build environment... But it might take a while to understand what is happening.)
Created attachment 173855 [details] [review] Use m4 to store .m4 files Hello Alejandro, could you try if this patch fixes the problem?
1. We don't use .gitignore. 2. The m4/ dir is not necessary, and the warning is red herring. Everything works just fine without it.
(In reply to comment #8) > 2. The m4/ dir is not necessary, and the warning is red herring. Everything > works just fine without it. So you are saying that my compilation problem, and build.gnome.org compilation problem should be solved on my compilation environment and on build.gnome.org? Sincerely, I really doubt that build.gnome.org is placing the m4 stuff in non-standard locations. And if this is the case with my environment, just to note that this is the only module that it is failing.
Created attachment 174460 [details] [review] Fixup for the first commit. Please take a look at committing this patch (or telling me that you reviewed it). After Tor's comment, this patch should have been committed already, I think.
Behdad reviewed my patch through IRC, I just committed it: http://git.gnome.org/browse/pango/commit/?id=588847fe4b5ed905f3a035825567e08a3b4d516d