an update to automake-1.11?

Sam Varshavchik mrsam at courier-mta.com
Sun Jul 5 18:24:43 UTC 2009


Conrad Meyer writes:

> On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote:
>> *snip*
>>
>> With a subsequent release, you'll still
>> have to rebase your existing patch, if the new release did not fix the
>> original bug. As I understand, rpm's default settings now reject fuzz in
>> patch files, so you'll just have to do it, now. And since the likelyhood of
>> configure changing in a new release is no different than any other source
>> file getting changed, on average, believing that some work can be saved
>> just by choosing to patch a different file, then the one that really needs
>> to be patched, is somewhat naive.
> 
> The problem is that configure scripts are not written by a human, but 
> generated by autoconf. It is easy to make small changes to configure.ac and 
> generate large changes in configure. This makes it easier to rebase patches 
> against configure.ac.

The macros in configure.ac generally expand out to canned shell script 
fragments, with the macro's parameters substituted somewhere. Changing a 
parameter in configure.ac usually results in an equivalent substitution in 
configure.

Generally, only when one adds or removes entire macros from configure.ac, 
that's when this results in wholesale changes to configure.

In my experience, the overwhelming majority of fixups to configure scripts 
involve nothing more than adjusting someone's pathname, or compiler flags. 
For this kind of scope, rebuilding the entire configure script is overkill, 
and I wouldn't do it unless I audit it and verify whether or not upstream is 
relying on some specific behavior in the specific version of autoconf that 
was used to build the original configure script. Patching the configure 
script is much safer than patching configure.ac, then have autoconf grok all 
.m4 macros and rebuild the whole thing, likely ending up with a completely 
different beast, that not only includes your changes but who knows what 
else.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090705/770a73c4/attachment.sig>


More information about the fedora-devel-list mailing list