Created attachment 43480 [details] [review]
Use the recommended configure.ac instead configure.in

Created attachment 43481 [details] [review]
Update autotools configuration

Replace deprecated macros and use the new libtool syntax.
Also use silent rules to silence the build a bit

Any comments about the patches?

(In reply to comment #1)
> Created attachment 43480 [details] [review] [review]
> Use the recommended configure.ac instead configure.in

Tollef made this change in 2ec2007d8d23748cdf72eba8503940615722848e, so we can skip this one.

Comment on attachment 43481 [details] [review]
Update autotools configuration

Review of attachment 43481 [details] [review]:
-----------------------------------------------------------------

In general I'm really happy with these changes and would appreciate autoreconf not complaining to me anymore. There are a couple things I'd like to discuss, though.

::: Makefile.am
@@ +1,1 @@
> +ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}

This is only necessary for keeping the libtool macros in tree, right? And the $ACLOCAL_FLAGS is just to support gnome-autogen.sh?

::: configure.ac
@@ +1,1 @@
> +AC_PREREQ([2.63])

Any reason for this? We've got a pretty simple setup here. FWIW, xorg has much more conservative requirements and it hasn't really posed a problem for anything.

http://xorg.freedesktop.org/wiki/ModularDevelopersGuide#GNU_Build_System

@@ +5,5 @@
> +        [pkg-config])
> +
> +AC_CONFIG_HEADERS([config.h])
> +AC_CONFIG_SRCDIR([pkg-config.1])
> +AC_CONFIG_MACRO_DIR([m4])

This is just because of the libtool macros, right? I personally would rather not put the libtool macros in the tree. We're not going to commit them to the repo (at least now), so it doesn't buy us anything. I hope this doesn't cause problems with pkg.m4 being in the root directory, but I don't think we use any of those macros in our configure.

@@ +9,5 @@
> +AC_CONFIG_MACRO_DIR([m4])
> +AC_CONFIG_AUX_DIR([build-aux])
> +
> +AM_INIT_AUTOMAKE([1.10])
> +AM_MAINTAINER_MODE([enable])

This got dropped a while back in master and if we want to reintroduce it that should be a separate discussion.

@@ +22,4 @@
>  
> +# Initialize libtool
> +LT_PREREQ([2.2])
> +LT_INIT

Again, any reason for the newish libtool? It might not matter, but I'm sure older libtool would be fine for us.

I committed your patch with a few edits in commit 7a8cc77.

* I changed the autotools versions to match our internal glib2 exactly.

* I left out the m4 directory since I don't like the idea of libtool installing its macros in the tree. If someone needs to run libtoolize again for any reason, they're going to prefer the libtool version on their system, I think.

* I left out the build-aux change. No real reason, I just felt it was superfluous and doesn't provide any real benefits. I've done it both ways, though.