4:47 p.m.
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.
4:55 p.m.
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/
5:32 p.m.
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(a)byu.net
5:37 p.m.
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/
5:17 a.m.
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 :|
5:15 a.m.
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 :|
6:30 a.m.
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(a)byu.net
From 59d8114ee4717da16d5f6d0f904af62d069d35b5 Mon Sep 17 00:00:00 2001
From: Eric Blake <ebb9(a)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(a)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
7:29 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
7:56 a.m.
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 :|
8:01 a.m.
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(a)byu.net
9:02 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
5451
days inactive
5453
days old
10 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Diego Elio “Flameeyes” Pettenò -
Eric Blake