[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FYI] NEWS: document fix for automake bug#13514
From: |
Stefano Lattarini |
Subject: |
Re: [FYI] NEWS: document fix for automake bug#13514 |
Date: |
Sun, 21 Apr 2013 17:05:37 +0200 |
[Re-adding the list]
On 04/21/2013 12:37 PM, Jack Kelly wrote:
> Stefano Lattarini <address@hidden> writes:
>> On 04/21/2013 11:28 AM, Jack Kelly wrote:
>>> Stefano Lattarini <address@hidden> writes:
>>>> + - Aclocal no longer consider directories for extra m4 files more than
>>>> + once, even if they are specified multiple times. This prevents
>>>> + problems in older packages that specify both
>>
>> It is; in fact, it is the right thing to do to support both Automake < 1.13
>> and Automake 1.13.x. The bug was due to the fact that this usage wasn't
>> correctly supported in some corner-cases.
>>
>> If the NEWS entry does not make that clear, I'd gladly accept suggestions
>> on how to improve it.
>
> It comes across like making the old packages work is a side-effect of
> fixing the double-listing for other reasons. Possibly because it's not
> obvious that the fix is connected to the breaking behaviour in old
> packages.
>
> Should "Aclocal" be written in lower-case or in quotes?
>
> The best I can come up with is this:
>
> aclocal will no longer consider directories for extra m4 files more than
> once, even if they are specified multiple times. This ensures packages
> that specify both
>
> AC_CONFIG_MACRO_DIR([m4])
>
> and
>
> ACLOCAL_AMFLAGS = -I m4
>
> will work correctly. (Both are needed for automake < 1.13 .)
>
I like this wording. I have prepared a patch using it, with minor adjustments.
The patch is below. Opinions?
> Note: ACLOCAL_AMFLAGS is deprecated and future versions (over the next
> several years) will raise warnings and errors before its final removal.
>
OTOH, this is already reported in the "Future backward incompatibilities"
section of NEWS, so there is no need to repeat it here.
Thanks,
Stefano
---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ---- >8 ----
>From 197f746ea059f63422c3c6f5fac841691f72ecca Mon Sep 17 00:00:00 2001
Message-Id: <address@hidden>
From: Stefano Lattarini <address@hidden>
Date: Sun, 21 Apr 2013 16:59:05 +0200
Subject: [PATCH] NEWS: improve wording for automake bug#13514 fix
Helped-by: Jack Kelly <address@hidden>
Signed-off-by: Stefano Lattarini <address@hidden>
---
NEWS | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/NEWS b/NEWS
index 06c012f..b8d65df 100644
--- a/NEWS
+++ b/NEWS
@@ -127,23 +127,23 @@ New in 1.13.2:
Automake 1.13, has turned out to be a similarly very bad idea,
for exactly the same reason.
- - Aclocal no longer error out if the first local m4 directory (as
+ - aclocal no longer error out if the first local m4 directory (as
specified by the '-I' option or the 'AC_CONFIG_MACRO_DIRS' or
'AC_CONFIG_MACRO_DIR' macros) doesn't exist; it merely report a
warning in the 'unsupported' category. This is done to support
- some pre-existing real-world usages; refer to automake bug#13514
- for more details.
+ some pre-existing real-world usages. See automake bug#13514.
- - Aclocal no longer consider directories for extra m4 files more than
- once, even if they are specified multiple times. This prevents
- problems in older packages that specify both
+ - aclocal will no longer consider directories for extra m4 files more
+ than once, even if they are specified multiple times. This ensures
+ packages that specify both
AC_CONFIG_MACRO_DIR([m4]) in configure.ac
ACLOCAL_AMFLAGS = -I m4 in Makefile.am
- If the 'm4' directory did not exist when aclocal was called the first
- time by autoreconf, an error would have ensued with Automake 1.13 and
- 1.13.1. See automake bug#13514.
+ will work correctly, even when the 'm4' directory contains no
+ package-specific files, but is used only to install third-party
+ m4 files (as can happen with e.g., "libtoolize --install").
+ See automake bug#13514.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.8.2.1.389.gcaa7d79