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
