Created attachment 153181 [details] [review]
Modernize autotools configuration

New requirements:

autoconf >= 2.63.2
automake >= 1.10
libtool >= 2.2.6

Javier: I am commenting here out of convenience, but this is a general issue with this GnomeGoal: I do not think autoconf >= 2.63.2 is correct or acceptable:

 - there is no 2.63.2 on ftp://ftp.gnu.org/gnu/autoconf
 - version of Fedora 12 (which is a very modern distribution) is 2.63
 - version in jhbuild is 2.63

So either the version is bumped to 2.64 and the version in jhbuild updated accordingly or the requirement relaxed a bit. Since passing the url in AC_INIT does not look so important, I'd prefer the latter

Created attachment 153202 [details] [review]
Modernize autotools configuration.v2

As discussed in IRC, check for 2.64 instead.
Added a bug to upgrade the jhbuild version to the latest autoconf version (2.65)

What do 2.63.2 or 2.64 bring that 2.63 doesn't? Esp., 2.63.2 looks a lot like 2.63 + some bugfixes...

Hello Steve,

2.63b introduced [1] a interesting feature I've used in the patch:

"AC_INIT now takes an optional fifth parameter that can be used to
AC_PACKAGE_URL, a URL for the package's home page; the URL is
used in `configure --help' and is also available via AC_DEFINE."


[1] http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=NEWS;h=207325eb653bcec682e68f918ade0c7a87930a74;hb=HEAD#l148

Just realized that libpeas doesn't have 'homepage' (I though this bug was for gedit), so maybe 2.63 would be enough

Review of attachment 153202 [details] [review]:

Javier, could you please update your patch against git master? Usage of introspection.m4 got in in the meantime so your patch doesn't apply anymore.

Thanks!

::: Makefile.am
@@ +4,3 @@
 SUBDIRS = libpeas libpeasui loaders data peas-demo po docs
+
+DISTCHECK_CONFIGURE_FLAGS=--enable-gtk-doc

Is there a reason why you moved this line downwards?

::: autogen.sh
@@ +21,3 @@
 }
 
+REQUIRED_MACROS=python.m4 USE_GNOME2_MACROS=1 USE_COMMON_DOC_BUILD=yes . gnome-autogen.sh

So REQUIERD_AUTOMAKE_VERSION isn't usefull anymore?

::: configure.ac
@@ -44,3 @@
-PKG_PROG_PKG_CONFIG
-
-AC_PROG_LIBTOOL

AC_PROG_LIBTOOL is deprecated?

@@ +51,3 @@
+
+# Checks for header files.
+AC_CHECK_HEADERS([libintl.h string.h])

Is this check usefull at all? I can't imagine of a system not shipping string.h, and we don't use HAVE_STRING_H or HAVE_LIBINTL_H in the code...

@@ +89,2 @@
 AM_GLIB_GNU_GETTEXT
+AC_DEFINE([GETTEXT_PACKAGE], [PACKAGE_TARNAME], [Define to the gettext package name.])

Why do you use PACKAGE_TARNAME? If you can do so, then you probably should do it too for the AC_SUBST.

@@ +341,3 @@
 
+GNOME_COMPILE_WARNINGS([maximum])
+GNOME_MAINTAINER_MODE_DEFINES

Does it handle --enable-deprecations ?

Created attachment 159447 [details] [review]
Modernize autotools configuration.v3

New requirements:
    autoconf >= 2.63
    automake >= 1.11
    libtool >= 2.2.6
    gtk-doc >= 1.12

(In reply to comment #7)
> Review of attachment 153202 [details] [review]:
> 
> Javier, could you please update your patch against git master? Usage of
> introspection.m4 got in in the meantime so your patch doesn't apply anymore.

Sure ;)

 
> +REQUIRED_MACROS=python.m4 USE_GNOME2_MACROS=1 USE_COMMON_DOC_BUILD=yes .
> gnome-autogen.sh
> 
> So REQUIERD_AUTOMAKE_VERSION isn't usefull anymore?

Nope, It's enougth with AM_INIT_AUTOMAKE([1.11]) in the configure.ac

> ::: configure.ac
> @@ -44,3 @@
> -PKG_PROG_PKG_CONFIG
> -
> -AC_PROG_LIBTOOL
> 
> AC_PROG_LIBTOOL is deprecated?

Yes, the new syntax is used now: LT_INIT([disable-static])

 
> @@ +51,3 @@
> +
> +# Checks for header files.
> +AC_CHECK_HEADERS([libintl.h string.h])
> 
> Is this check usefull at all? I can't imagine of a system not shipping
> string.h, and we don't use HAVE_STRING_H or HAVE_LIBINTL_H in the code...

Removed

> @@ +89,2 @@
>  AM_GLIB_GNU_GETTEXT
> +AC_DEFINE([GETTEXT_PACKAGE], [PACKAGE_TARNAME], [Define to the gettext package
> name.])
> 
> Why do you use PACKAGE_TARNAME? If you can do so, then you probably should do it too for the AC_SUBST.

Fixed

> 
> @@ +341,3 @@
> 
> +GNOME_COMPILE_WARNINGS([maximum])
> +GNOME_MAINTAINER_MODE_DEFINES
> 
> Does it handle --enable-deprecations ?

Yes, take a look to the GNOME_MAINTAINER_MODE_DEFINES if you want:
http://git.gnome.org/browse/gnome-common/tree/macros2/gnome-common.m4#n34

This has been fixed in master. Thanks!