an update to automake-1.11?

Kevin Kofler kevin.kofler at chello.at
Tue Jul 7 23:49:28 UTC 2009


Sam Varshavchik wrote:
> This may come as a shock to some, but configure does not often change
> unless configure.ac changes too.
> 
> So, I'm not sure what does the frequency of changes to configure.ac has to
> do with anything.

Where your argument falls apart is that patch fuzz is a local concept! It's 
irrelevant that the file is not byte-identical. What matters is whether the 
context lines directly above and below the line(s) you're patching changed. 
And that's a lot more likely to happen for configure than for configure.ac.

> If someone thinks that by patching configure.ac, instead of configure, one
> achieves tremendous savings in the frequency of needing to rebase one's
> patches, they're in a desperate need for a reality check.

No, they're just more familiar with how patch(1) works than you.

> Furthermore, changes to configure.ac will more likely to result in a more
> frequent manual rebases, where the corresponding changes in configure are
> far more likely to result in much simpler rebasing that's limited only to
> eliminating the fuzz. If one patches a line or two in configure.ac, then
> if the upstream futzes around with a neighboring line, the patch is going
> to get kicked out, and must be manually rebased. On the other hand, if a
> corresponding patch was against configure, instead, (and by that I mean a
> real patch, and not a patch to configure.ac followed by autoconf followed
> by a diff of the new configure against the old, I hate to explicitly say
> this, but some folks around here have a mental block on this subject, and
> can't wrap their brains around the concept of patching configure
> directly), the corresponding differences in configure would've ended up
> being hundred of lines apart, resulting in nothing more than some fuzz,
> that can be automatically updated.

Huh? It's quite the opposite, as those "hundred (sic) of lines" which are 
inserted automatically (i.e. which do NOT come from configure.ac) are the 
ones most likely to change, it just takes upstream using a different 
autoconf (and they WILL do that, it's only in your dream world that all 
upstreams use a fixed autoconf binary and never change it, only a few 
projects like GCC do that, and even there, the version changes from time to 
time) and those lines will be completely different.

        Kevin Kofler





More information about the fedora-devel-list mailing list