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

[Stefano Lattarini]

Hi Pavel.

On 03/05/2013 02:56 PM, Pavel Raiskup wrote:
> 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 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