[PATCH] build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER

[Stefano Lattarini]

* configure.ac: Here. The latter has been removed in Automake 1.13.

Signed-off-by: Stefano Lattarini <stefano....@gmail.com>
Copyright-paperwork-exempt: yes
---
ChangeLog | 5 +++++
configure.ac | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 83109e7..133b56a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2012-12-29 Stefano Lattarini <stefano....@gnu.org> (tiny change)
+
+ build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER
+ * configure.ac: Here. The latter has been removed in Automake 1.13.
+
2012-12-21 Paolo Bonzini <bon...@gnu.org>

* configure.ac: Bump version number. Replace COPYRIGHT_YEAR.
diff --git a/configure.ac b/configure.ac
index 9d33ec9..c89f368 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,7 +2,7 @@ dnl Process this file with -*- autoconf -*- to produce a configure script.
AC_INIT([GNU sed], 4.2.2, bug...@gnu.org, sed)
AC_CONFIG_AUX_DIR(build-aux)
AC_CONFIG_SRCDIR([sed/sed.c])
-AM_CONFIG_HEADER(config.h:config_h.in)
+AC_CONFIG_HEADERS(config.h:config_h.in)
AC_PREREQ(2.60)
AM_INIT_AUTOMAKE

--
1.8.1.rc3.27.g3b73c7d

[Paolo Bonzini]

Il 29/12/2012 17:32, Stefano Lattarini ha scritto:
> * configure.ac: Here. The latter has been removed in Automake 1.13.

Is there any reason for this, apart from randomly breaking
perfectly-working packages?

The right way to do this is to rely on the autoupdate machinery.

Paolo

[Paolo Bonzini]

Il 29/12/2012 17:32, Stefano Lattarini ha scritto:
> * configure.ac: Here. The latter has been removed in Automake 1.13.
>

The other patches look fine, but you will have to find someone to commit
them. Karl, Paul, any volunteers?

Paolo

[Stefano Lattarini]

On 12/29/2012 08:46 PM, Paolo Bonzini wrote:
> Il 29/12/2012 17:32, Stefano Lattarini ha scritto:
>> * configure.ac: Here. The latter has been removed in Automake 1.13.
>

> Is there any reason for this,
>

Avoiding to keep too much cruft around the codebase, and smoothing
possible future transitions to Automake-NG.

> apart from randomly breaking
> perfectly-working packages?
>
> The right way to do this is to rely on the autoupdate machinery.
>

I thought I had deprecated this macro in the 1.12.x series already,
with proper warnings. Wasn't that the case? If not, I apologize for
the inconvenience; while it's worth noting that the AM_CONFIG_HEADER
macro has been clearly deprecated in the manual for a long time, I
understand that that kind of deprecation can be easily missed, and
a runtime warning is much more helpful and user-friendly.

Stefano

[Paul Eggert]

On 12/29/2012 11:49 AM, Paolo Bonzini wrote:
> Karl, Paul, any volunteers?

I can volunteer to do commits, if you add me to the
list of committers for sed.

[Karl Berry]

I can volunteer to do commits,

Paul, does this mean you are volunteering to be a new maintainer for
sed, for the time being at least? We can still look for new people, of
course. Anyone else want to join in? We need one, of course.

(Ditto grep, not that that's relevant for this mailing list. :)

karl

[Paul Eggert]

On 12/29/2012 02:29 PM, Karl Berry wrote:
> Paul, does this mean you are volunteering to be a new maintainer for
> sed, for the time being at least?

I'd rather not, as I'm maintainer for too many projects
already, and don't know much about sed. But I can commit
obvious fixes, such as the ones already posted.

grep has three maintainers now, no? So it should be OK.

[Paolo Bonzini]

Il 29/12/2012 21:43, Stefano Lattarini ha scritto:
> On 12/29/2012 08:46 PM, Paolo Bonzini wrote:
>> Il 29/12/2012 17:32, Stefano Lattarini ha scritto:
>>> * configure.ac: Here. The latter has been removed in Automake 1.13.
>>
>> Is there any reason for this,
>>
> Avoiding to keep too much cruft around the codebase, and smoothing
> possible future transitions to Automake-NG.

Two lines of code are not "cruft". It's only cruft if it happens
_outside_ the definition of AM_CONFIG_HEADER itself.

>> apart from randomly breaking
>> perfectly-working packages?
>>
>> The right way to do this is to rely on the autoupdate machinery.
>>
> I thought I had deprecated this macro in the 1.12.x series already,
> with proper warnings. Wasn't that the case?

Deprecating is different from letting autoupdate convert it automatically.

> If not, I apologize for
> the inconvenience; while it's worth noting that the AM_CONFIG_HEADER
> macro has been clearly deprecated in the manual for a long time, I
> understand that that kind of deprecation can be easily missed, and
> a runtime warning is much more helpful and user-friendly.

Note that this sort of random breakage (or at least, this is how it is
perceived by users) is the main reason for hatred of Autotools. It used
to be (around Autoconf 2.50-2.53, and Automake 1.4-1.6) that a
medium-sized project took a day to upgrade. Things have been much much
smoother for the past 5-8 years, yet the memories remain. Please do not
bring that time back.

Paolo

[Paolo Bonzini]

Il 30/12/2012 01:43, Paul Eggert ha scritto:
>> > Paul, does this mean you are volunteering to be a new maintainer for
>> > sed, for the time being at least?
> I'd rather not, as I'm maintainer for too many projects
> already, and don't know much about sed. But I can commit
> obvious fixes, such as the ones already posted.

I made you a Savannah admin for sed, I think that includes committing
obvious fixes.

Paolo

[Stefano Lattarini]

On 12/30/2012 10:35 AM, Paolo Bonzini wrote:
> Il 29/12/2012 21:43, Stefano Lattarini ha scritto:
>> On 12/29/2012 08:46 PM, Paolo Bonzini wrote:
>>> Il 29/12/2012 17:32, Stefano Lattarini ha scritto:
>>>> * configure.ac: Here. The latter has been removed in Automake 1.13.
>>>
>>> Is there any reason for this,
>>>
>> Avoiding to keep too much cruft around the codebase, and smoothing
>> possible future transitions to Automake-NG.
>
> Two lines of code are not "cruft". It's only cruft if it happens
> _outside_ the definition of AM_CONFIG_HEADER itself.
>
>>> apart from randomly breaking
>>> perfectly-working packages?
>>>
>>> The right way to do this is to rely on the autoupdate machinery.
>>>
>> I thought I had deprecated this macro in the 1.12.x series already,
>> with proper warnings. Wasn't that the case?
>
> Deprecating is different from letting autoupdate convert it automatically.
>

At any rate, I agree the error message caused by the abrupt removal
is horrible. I'll soon post a patch to have still-exiting uses of
AM_CONFIG_HEADER give a clear error message (as is done for the
AM_C_PROTOTYPES since Automake 1.12). Making that fix quickly
available will be a good reason for a 1.13.1 release.

> [SNIP]

Regards,
Stefano

[Stefano Lattarini]

Hi Pavel.

On 03/05/2013 02:56 PM, Pavel Raiskup wrote:
> Dear Stefano, sorry for so late response,

> I'm still thinking about this resolution. Could you please reconsider
> again this situation? We have in Fedora 18 about 700+ packages dependent
> on automake. I gues
>
No need to, the AM_CONFIG_HEADER will be re-introduced in 1.13.2 (it will
raise a warning, but no fatal error). Not sure when I'll have proper time
to tie the loose ends still present in the repo, and roll a new beta for
1.13.2, though, so just be patient.

> s that other distributions have similar numbers.
> Quite a lot of these packages are still dependent on AM_CONFIG_HEADER,
> etc.
>
> The future incompatibility is *not* big pain for developers; but mostly
> for disto build systems :(
>
I hadn't consider this aspect originally. Still, the issue can in the
meantime wroked around by having you packagers patch the automake used
to package re-bootstrapping (unfortunately, having you simply redefine
AM_CONFIG_HEADER in a custom $ACLOCAL_PATH entry is not an option ATM,
since currently Automake prefers its own m4 macros unconadionaly; that
will be fixed in the next major version, where Automake will give
precedence to definitions in $ACLOCAL_PATH entries).

Maintainers are thus forced not to do updates
> for automake because of these problems ~> and users will not have then
> easy access to the newest up2date automake source. I know that because I
> have done the automake update to 1.13 and it was **too** early. My bad I
> know - I should know that but it seems to be quite unnecessary.
>
> Important to note is that I really don't want to make multiple packages like
> automake113/automake114/(or whatever new version it will be). I just
> want to have one easy and stable package 'automake'. I don't want to have the
> same source in distribution multiple times — to fix some security/code problems
> on multiple places each time they comes.
>
> The only solution for me was revert as quickly as possible your changes —
> re-add obsoleted macros back to automake downstream. And next time I'll be
> definitely **much more** careful. Could you please look at it once again
> please?
>
> [SNIP]
>
> First of all, please consider re-adding the obsolete macros back to
> automake, it would be really appreciated.
>
It's already done. You'll just have to wait for the fix to hit a released
version, sorry.

Regards,
Stefano

[Pavel Raiskup]

Dear Stefano, sorry for so late response,

> On 12/30/2012 10:35 AM, Paolo Bonzini wrote:
>> Il 29/12/2012 21:43, Stefano Lattarini ha scritto:
>>> On 12/29/2012 08:46 PM, Paolo Bonzini wrote:
>>>> Il 29/12/2012 17:32, Stefano Lattarini ha scritto:
>>>>> * configure.ac: Here. The latter has been removed in Automake 1.13.
>>>>
>>>> Is there any reason for this,
>>>>
>>> Avoiding to keep too much cruft around the codebase, and smoothing
>>> possible future transitions to Automake-NG.
>>
>> Two lines of code are not "cruft". It's only cruft if it happens
>> _outside_ the definition of AM_CONFIG_HEADER itself.
>>
>>>> apart from randomly breaking
>>>> perfectly-working packages?
>>>>
>>>> The right way to do this is to rely on the autoupdate machinery.
>>>>
>>> I thought I had deprecated this macro in the 1.12.x series already,
>>> with proper warnings. Wasn't that the case?
>>
>> Deprecating is different from letting autoupdate convert it automatically.
>>
> At any rate, I agree the error message caused by the abrupt removal
> is horrible. I'll soon post a patch to have still-exiting uses of
> AM_CONFIG_HEADER give a clear error message (as is done for the
> AM_C_PROTOTYPES since Automake 1.12). Making that fix quickly
> available will be a good reason for a 1.13.1 release.

I'm still thinking about this resolution. Could you please reconsider
again this situation? We have in Fedora 18 about 700+ packages dependent

on automake. I guess that other distributions have similar numbers.

Quite a lot of these packages are still dependent on AM_CONFIG_HEADER,
etc.

The future incompatibility is *not* big pain for developers; but mostly

for disto build systems :(. Maintainers are thus forced not to do updates

for automake because of these problems ~> and users will not have then
easy access to the newest up2date automake source. I know that because I
have done the automake update to 1.13 and it was **too** early. My bad I
know - I should know that but it seems to be quite unnecessary.

Important to note is that I really don't want to make multiple packages like
automake113/automake114/(or whatever new version it will be). I just
want to have one easy and stable package 'automake'. I don't want to have the
same source in distribution multiple times — to fix some security/code problems
on multiple places each time they comes.

The only solution for me was revert as quickly as possible your changes —
re-add obsoleted macros back to automake downstream. And next time I'll be
definitely **much more** careful. Could you please look at it once again

please? I can help you with patch preparation if you consider this as
suitable. No big need for testing this — just re-add the AU_DEFUN statements
for old macros.

======================

I was thinking about this one quite a long time. Firstly I was thinking
about "how to get rid of these macros in my distro". There are some
possibilities worth to try. But the main question is: Why?! these old
macros are _still_ alive? There are dead packages using legacy macros of
course - but it is a different story. I think that the most important
thing is because you are not telling this clearly to users. I just want
to say that the 'obsolete' warnings are disabled by default, why? Could
we discuss this? Btw., by grepping our spec files - I found three
packages using the -W option in autoconf/automake/autoreconf.

I don't want to set $WARNINGS system-wide. Do you see another solutions?
I know that this more about autoconf - but still, you may stop me before I
raise autoconf mailing list.

First of all, please consider re-adding the obsolete macros back to
automake, it would be really appreciated.

Thanks for discussion :),
Pavel