2:24 p.m.
boostrap.conf lists gzip as build dependency. bootstrap then tries to
get it's version number using a get_version() function that executes
'gzio --version' and tries to parse the result.
The sed expression expects the version number to contain a dot as gzip
outputs it on Linux:
$ gzip --version
gzip 1.3.12
But on FreeBSD it outputs this:
# gzip --version
FreeBSD gzip 20100407
Therefore, the sed expression should be relaxed, or bootstrap should
not try to parse the version number when it doesn't need it because
gzip is listed with '-' as version requirement.
Matthias
2:50 p.m.
[adding bug-gnulib]
On 11/12/2010 01:24 PM, Matthias Bolte wrote:
boostrap.conf lists gzip as build dependency. bootstrap then tries
to
get it's version number using a get_version() function that executes
'gzio --version' and tries to parse the result.
The sed expression expects the version number to contain a dot as gzip
outputs it on Linux:
$ gzip --version
gzip 1.3.12
But on FreeBSD it outputs this:
# gzip --version
FreeBSD gzip 20100407
Therefore, the sed expression should be relaxed, or bootstrap should
not try to parse the version number when it doesn't need it because
gzip is listed with '-' as version requirement.
I'm pushing this to fix the gnulib side of things; a libvirt patch to
use the latest gnulib will follow shortly.
diff --git i/ChangeLog w/ChangeLog
index e348fe2..8a9d7b6 100644
--- i/ChangeLog
+++ w/ChangeLog
@@ -1,5 +1,11 @@
2010-11-12 Eric Blake <eblake(a)redhat.com>
+ bootstrap: allow FreeBSD gzip
+ * build-aux/bootstrap (get_version): Parse FreeBSD gzip version,
+ which has no '.' and goes to stderr.
+ * build-aux/bootstrap.conf (buildreq): Improve the sample file.
+ Reported by Matthias Bolte.
+
maintainer-makefile: check for i18n setup
* top/maint.mk (sc_bindtextdomain): Check for evidence that _()
will likely work.
diff --git i/build-aux/bootstrap w/build-aux/bootstrap
index 8c8d777..5278e8e 100755
--- i/build-aux/bootstrap
+++ w/build-aux/bootstrap
@@ -1,6 +1,6 @@
#! /bin/sh
# Print a version string.
-scriptversion=2010-10-08.16; # UTC
+scriptversion=2010-11-12.20; # UTC
# Bootstrap this package from checked-out sources.
@@ -345,11 +345,11 @@ get_version() {
$app --version 2>&1 |
sed -n '# extract version within line
- s/.*[v ]\{1,\}\([0-9]\{1,\}\.[.a-z0-9-]*\).*/\1/
+ s/.*[v ]\{1,\}\([0-9]\{1,\}\(\.[.a-z0-9-]*\)*\).*/\1/
t done
# extract version at start of line
- s/^\([0-9]\{1,\}\.[.a-z0-9-]*\).*/\1/
+ s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/
t done
d
diff --git i/build-aux/bootstrap.conf w/build-aux/bootstrap.conf
index 75cf6ff..2bb60e2 100644
--- i/build-aux/bootstrap.conf
+++ w/build-aux/bootstrap.conf
@@ -57,3 +57,11 @@ if test $gettext_external = 1; then
m4/xsize.m4
'
fi
+
+# Build prerequisites
+buildreq="\
+autoconf 2.59
+automake 1.9.6
+git 1.5.5
+tar -
+"
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:40 p.m.
On 11/12/2010 02:35 PM, Paul Eggert wrote:
On 11/12/2010 12:50 PM, Eric Blake wrote:
> + s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/
Surely that is a typo. The "*\)\)*" should be a "*\)*\)".
Aargh - I tested on one machine, but committed on another. Typo is now
fixed.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
12:58 a.m.
Hello,
* Eric Blake wrote on Fri, Nov 12, 2010 at 10:40:25PM CET:
On 11/12/2010 02:35 PM, Paul Eggert wrote:
> On 11/12/2010 12:50 PM, Eric Blake wrote:
>> + s/^\([0-9]\{1,\}\(\.[.a-z0-9-]*\)\)*.*/\1/
>
> Surely that is a typo. The "*\)\)*" should be a "*\)*\)".
Aargh - I tested on one machine, but committed on another. Typo is now
fixed.
But the following limitations from autoconf.info still apply:
Nested parentheses in patterns (e.g., `\(\(a*\)b*)\)') are quite
portable to current hosts, but was not supported by some ancient
`sed' implementations like SVR3.
Some `sed' implementations, e.g., Solaris, restrict the special
role of the asterisk `*' to one-character regular expressions and
back-references, and the special role of interval expressions
`\{M\}', `\{M,\}', or `\{M,N\}' to one-character regular
expressions. This may lead to unexpected behavior:
You can probably ignore the first, but not the second.
Cheers,
Ralf
5123
days inactive
5124
days old
4 comments
4 participants
participants (4)
-
Eric Blake -
Matthias Bolte -
Paul Eggert -
Ralf Wildenhues