[libvirt] [PATCH 1/n] modernizing configure
I just built libvirt for the first time today, and noticed that configure fails on the first missing dependency, rather than trying harder to make it through and list all missing dependencies at the end. I ended up restarting configure multiple times. In the process, I also noticed that configure is somewhat out of date. So, what is the oldest version of autoconf and automake that libvirt will insist on supporting? For example, is it time to require automake 1.11.1 (the latest stable release) because of its security patch to avoid potential problems in 'make dist'? Or is it too soon to expect all distros to have an automake that new pre-installed, and more effort be put into supporting automake 1.9.6 and autoconf 2.59 (those being the implicit minimum requirements due to the use of gnulib)? Or somewhere in between? Meanwhile, how about this patch, for me getting my feet wet in helping to modernize the autotools usage, and hopefully leading up to future patches to make configure list all missing dependencies at once, rather than requiring multiple restarts.
Il giorno sab, 23/01/2010 alle 15.47 -0700, Eric Blake ha scritto:
Or is it too soon to expect all distros to have an automake that new pre-installed, and more effort be put into supporting automake 1.9.6 and autoconf 2.59 (those being the implicit minimum requirements due to the use of gnulib)? Or somewhere in between?
I asked about that as well a few days ago, seems like the lower bound is RHEL-5 which means nothing more than autoconf 2.59 can be used :( -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
According to Diego Elio “Flameeyes” Pettenò on 1/23/2010 3:55 PM:
Il giorno sab, 23/01/2010 alle 15.47 -0700, Eric Blake ha scritto:
Or is it too soon to expect all distros to have an automake that new pre-installed, and more effort be put into supporting automake 1.9.6 and autoconf 2.59 (those being the implicit minimum requirements due to the use of gnulib)? Or somewhere in between?
I asked about that as well a few days ago, seems like the lower bound is RHEL-5 which means nothing more than autoconf 2.59 can be used :(
There's a difference between supporting tarballs on RHEL-5 (where the version of autoconf and automake is irrelevant, since you don't have to run the autotools to build from a tarball) and actually developing on RHEL-5 (where the developer has to install prerequisites like newer autotools if the package decides to require newer autotools). Is there anyone that seriously falls in the latter category, of still wanting to _develop_ libvirt on RHEL-5? Or am I correct in assuming that _development_ is limited to more modern distros, where only tarball portability to older systems is still necessary. -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@byu.net
Il giorno sab, 23/01/2010 alle 16.32 -0700, Eric Blake ha scritto:
Is there anyone that seriously falls in the latter category, of still wanting to _develop_ libvirt on RHEL-5?
The post is at worst two weeks old, you can easily find it in the archives (search for my name in the page, I don't post that often so you should find the thread easily). It's interest of the main developers to keep being able to use the autotools as shipped by RHEL-5. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/
On Sat, Jan 23, 2010 at 04:32:34PM -0700, Eric Blake wrote:
According to Diego Elio ???Flameeyes??? Pettenò on 1/23/2010 3:55 PM:
Il giorno sab, 23/01/2010 alle 15.47 -0700, Eric Blake ha scritto:
Or is it too soon to expect all distros to have an automake that new pre-installed, and more effort be put into supporting automake 1.9.6 and autoconf 2.59 (those being the implicit minimum requirements due to the use of gnulib)? Or somewhere in between?
I asked about that as well a few days ago, seems like the lower bound is RHEL-5 which means nothing more than autoconf 2.59 can be used :(
There's a difference between supporting tarballs on RHEL-5 (where the version of autoconf and automake is irrelevant, since you don't have to run the autotools to build from a tarball) and actually developing on RHEL-5 (where the developer has to install prerequisites like newer autotools if the package decides to require newer autotools). Is there anyone that seriously falls in the latter category, of still wanting to _develop_ libvirt on RHEL-5?
Yes, because we need to make sure that libvirt continues to work with the RHEL-5 era Xen platform, and this requires being able to fully build from GIT source. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Sat, Jan 23, 2010 at 03:47:37PM -0700, Eric Blake wrote:
I just built libvirt for the first time today, and noticed that configure fails on the first missing dependency, rather than trying harder to make it through and list all missing dependencies at the end. I ended up restarting configure multiple times. In the process, I also noticed that configure is somewhat out of date.
So, what is the oldest version of autoconf and automake that libvirt will insist on supporting? For example, is it time to require automake 1.11.1 (the latest stable release) because of its security patch to avoid potential problems in 'make dist'? Or is it too soon to expect all distros to have an automake that new pre-installed, and more effort be put into supporting automake 1.9.6 and autoconf 2.59 (those being the implicit minimum requirements due to the use of gnulib)? Or somewhere in between?
RHEL5 is the minimum required platform, including full bootstrap from GIT source. This implies automake-1.9.6-2.1 and autoconf-2.59-12 Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
According to Daniel P. Berrange on 1/25/2010 4:15 AM:
So, what is the oldest version of autoconf and automake that libvirt will insist on supporting?
RHEL5 is the minimum required platform, including full bootstrap from GIT source. This implies automake-1.9.6-2.1 and autoconf-2.59-12
Fair enough. That said, my patch to rename to configure.ac and use the more modern AC_CONFIG_HEADERS is still relevant, as both of those were supported in autoconf 2.59. I noticed the patch got attached with binary mime type last time; (I'm still fighting with email configuration of the machine where I first built the patch), so here it is again in plain text. -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@byu.net
From 59d8114ee4717da16d5f6d0f904af62d069d35b5 Mon Sep 17 00:00:00 2001 From: Eric Blake <ebb9@byu.net> Date: Sat, 23 Jan 2010 15:14:09 -0700 Subject: [PATCH] Start modernizing configure.
* configure.in: Move... * configure.ac: ...here. (AM_CONFIG_HEADER): Replace obsolete macro... (AC_CONFIG_HEADERS): ...with modern replacement. Signed-off-by: Eric Blake <ebb9@byu.net> --- configure.in => configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) rename configure.in => configure.ac (99%) diff --git a/configure.in b/configure.ac similarity index 99% rename from configure.in rename to configure.ac index 8cbbfe5..32f376e 100644 --- a/configure.in +++ b/configure.ac @@ -3,7 +3,7 @@ dnl Process this file with autoconf to produce a configure script. AC_INIT([libvirt], [0.7.5]) AC_CONFIG_SRCDIR([src/libvirt.c]) AC_CONFIG_AUX_DIR([build-aux]) -AM_CONFIG_HEADER([config.h]) +AC_CONFIG_HEADERS([config.h]) dnl Make automake keep quiet about wildcards & other GNUmake-isms AM_INIT_AUTOMAKE([-Wno-portability]) -- 1.6.6
On Mon, Jan 25, 2010 at 05:30:23AM -0700, Eric Blake wrote:
According to Daniel P. Berrange on 1/25/2010 4:15 AM:
So, what is the oldest version of autoconf and automake that libvirt will insist on supporting?
RHEL5 is the minimum required platform, including full bootstrap from GIT source. This implies automake-1.9.6-2.1 and autoconf-2.59-12
Fair enough. That said, my patch to rename to configure.ac and use the more modern AC_CONFIG_HEADERS is still relevant, as both of those were supported in autoconf 2.59. I noticed the patch got attached with binary mime type last time; (I'm still fighting with email configuration of the machine where I first built the patch), so here it is again in plain text. [..] diff --git a/configure.in b/configure.ac
Sorry for being ignorant but what's the interest of renaming ? what does that change in practice ?
similarity index 99% rename from configure.in rename to configure.ac
index 8cbbfe5..32f376e 100644 --- a/configure.in +++ b/configure.ac @@ -3,7 +3,7 @@ dnl Process this file with autoconf to produce a configure script. AC_INIT([libvirt], [0.7.5]) AC_CONFIG_SRCDIR([src/libvirt.c]) AC_CONFIG_AUX_DIR([build-aux]) -AM_CONFIG_HEADER([config.h]) +AC_CONFIG_HEADERS([config.h]) dnl Make automake keep quiet about wildcards & other GNUmake-isms AM_INIT_AUTOMAKE([-Wno-portability])
Independantly of renaming, that looks fine to me, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Jan 25, 2010 at 02:29:35PM +0100, Daniel Veillard wrote:
On Mon, Jan 25, 2010 at 05:30:23AM -0700, Eric Blake wrote:
According to Daniel P. Berrange on 1/25/2010 4:15 AM:
So, what is the oldest version of autoconf and automake that libvirt will insist on supporting?
RHEL5 is the minimum required platform, including full bootstrap from GIT source. This implies automake-1.9.6-2.1 and autoconf-2.59-12
Fair enough. That said, my patch to rename to configure.ac and use the more modern AC_CONFIG_HEADERS is still relevant, as both of those were supported in autoconf 2.59. I noticed the patch got attached with binary mime type last time; (I'm still fighting with email configuration of the machine where I first built the patch), so here it is again in plain text. [..] diff --git a/configure.in b/configure.ac
Sorry for being ignorant but what's the interest of renaming ? what does that change in practice ?
IIUC, it is simply that "configure.ac" is the recommended naming convention from autoconf developers. Functionally I don't believe there's any difference.
similarity index 99% rename from configure.in rename to configure.ac
index 8cbbfe5..32f376e 100644 --- a/configure.in +++ b/configure.ac @@ -3,7 +3,7 @@ dnl Process this file with autoconf to produce a configure script. AC_INIT([libvirt], [0.7.5]) AC_CONFIG_SRCDIR([src/libvirt.c]) AC_CONFIG_AUX_DIR([build-aux]) -AM_CONFIG_HEADER([config.h]) +AC_CONFIG_HEADERS([config.h]) dnl Make automake keep quiet about wildcards & other GNUmake-isms AM_INIT_AUTOMAKE([-Wno-portability])
Independantly of renaming, that looks fine to me,
ACK to the whole patch from me, including the rename - we might as well follow the best practice here. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
According to Daniel Veillard on 1/25/2010 6:29 AM:
diff --git a/configure.in b/configure.ac
Sorry for being ignorant but what's the interest of renaming ? what does that change in practice ?
Conceptually, modern autoconf reserves the namespace *.in for template files that are fed to config.status to create the substituted files; but configure.in does not fit that paradigm (configure.in is not processed by config.status to generate configure). Using the name configure.ac gives a better indication of what tool is used in processing the file (comparable to Makefile.am processed by automake, which generates Makefile.in processed by config.status, which generates Makefile to be processed by make). Pragmatically, the renaming gets us one step closer to being able to run 'autoconf -Wall -Werror' as a way to check for other portability problems in configure.ac (although there are still a number of other things to address before -Werror will reliably work; in particular, gnulib still triggers some autoconf warnings for its use of obsolete macros).
-AM_CONFIG_HEADER([config.h]) +AC_CONFIG_HEADERS([config.h]) dnl Make automake keep quiet about wildcards & other GNUmake-isms AM_INIT_AUTOMAKE([-Wno-portability])
Independantly of renaming, that looks fine to me,
I don't have commit rights; would someone like to take over from here? -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@byu.net
On Mon, Jan 25, 2010 at 05:30:23AM -0700, Eric Blake wrote:
According to Daniel P. Berrange on 1/25/2010 4:15 AM:
So, what is the oldest version of autoconf and automake that libvirt will insist on supporting?
RHEL5 is the minimum required platform, including full bootstrap from GIT source. This implies automake-1.9.6-2.1 and autoconf-2.59-12
Fair enough. That said, my patch to rename to configure.ac and use the more modern AC_CONFIG_HEADERS is still relevant, as both of those were supported in autoconf 2.59. I noticed the patch got attached with binary mime type last time; (I'm still fighting with email configuration of the machine where I first built the patch), so here it is again in plain text.
Okidoc, pushed, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Diego Elio “Flameeyes” Pettenò -
Eric Blake