Re: [PATCH] build: use AC_CONFIG_HEADERS, not AM_CONFIG_HEADER

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