On Tue, 29 May 2012, Jan Engelhardt wrote:
On Tuesday 2012-05-29 16:53, Richard Guenther wrote:
On Tue, 29 May 2012, Jan Engelhardt wrote:
On Tuesday 2012-05-29 16:31, Richard Guenther wrote:
I find patches touching autogenerated files unwieldy to maintain.
Why exactly?
For example, there is a new warning in automake 1.12 that moans about AM_PROG_AR being absent when intending to create a .la archive. So, one has to add a *1-line* patch to the package iff it used AM_INIT_AUTOMAKE([-Werror]). The expanded form, as you suggest, of this change would be a 270+-line patch.
No. You don't need to patch anything here if you do not run autoreconf.
Indeed. But consider a2ps, which was also on the list. I am attempting to rebase the patches to a2ps-4.14.
I have seen at least one patch now that touched Makefile.ins in ways where I have no clue what the F the original patch creator did - or whether the diff is in fact the result of rerunning autoreconf or so.
In short: patches to Makefile.in are more often than not absolutely non-descriptive. All I can do about that is rip out hunks (avoiding the patch conflict) or in fact splice (resolve the conflict) them into 4.14, and neither choice gives me any confidence.
Oh, sure - you definitely should patch _both_, Makefile.in _and_
Makefile.am. And re-generate Makefile.in (and create a patch for it)
with exactly the same autotools versions that the file was created with
(to avoid spuriously large diffs).
Richard.
--
Richard Guenther