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
