[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: warn-on-use.m4 requires modern M4?
From: |
Jim Meyering |
Subject: |
Re: warn-on-use.m4 requires modern M4? |
Date: |
Tue, 12 Jan 2010 17:12:34 +0100 |
Eric Blake wrote:
> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> I get errors from autoreconf when bootstrapping Libidn on a Ubuntu 8.04
>> LTS system, and removing the recent warn-on-use.m4 file fixes it. Is
>> there something in the file that requires a recent GNU M4? Ubuntu 8.04
>> has GNU M4 1.1.10, and according to gnulib's DEPENDENCIES 1.4.5 or later
>> should be OK.
>
> m4 1.4.6 or better is preferred (and in fact, enforced by newer autoconf), but
> yes, 1.4.5 is okay with older autoconf.
>
> The problem is not old m4, but old autoconf. Which version are you using?
>
> Meanwhile, I can work around the problem by making sure warn-on-use.m4 defines
> enough helper macros if they are not already defined by autoconf. I just need
> to know which helper macros weren't available. We already guarantee
> m4_foreach_w in gnulib-common.m4, so I'm guessing that it might be AS_VAR_IF
> or
> AS_VAR_SET.
>
> <time passes>
>
> Sure enough, we have other uses of AS_VAR_SET in gnulib, but I appear to be
> the
> first user of AS_VAR_IF (well, warnings.m4 uses gl_AS_VAR_IF); that macro was
> only introduced in autoconf 2.63b, even though gnulib still claims to work
> with
> as old as 2.59.
>
> So, the right patch would be to move gl_AS_VAR_IF out of warnings.m4, and make
> gnulib-common.m4 define a fallback AS_VAR_IF. I'll take care of that.
>
> Meanwhile, based on the recent security hole in older automake, should we bite
> the bullet and require automake 1.10.3 or better (which in turn bumps the
> minimum autoconf requirement from 2.59 up to 2.60)?
That sounds worthwhile to me.
However, I'd go a little further and require
1.10.x, 3 <= x
or
1.11.y, 1 <= y
--------------
or maybe just exclude the buggy 1.11 release, like
require 1.10.3, but explicitly exclude 1.11.
But that doesn't address the problem with "1.11a",
which is what I tend to use, but which may come before
or after the 1.11.1 release.
IMHO, this is a good excuse to make automake switch to
using "git describe"-based --version output.