an update to automake-1.11?

Conrad Meyer cemeyer at u.washington.edu
Sun Jul 5 21:05:08 UTC 2009


On Sunday 05 July 2009 11:24:43 am Sam Varshavchik wrote:
> 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.

Right. Still, it makes more sense to patch the original source than the 
generated result, I think.

> 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.

Unrelated, but I think this sort of phobia of regenerating an auto-generated 
script just goes to show how completely broken autotools is.

Regards,
-- 
Conrad Meyer <cemeyer at u.washington.edu>




More information about the devel mailing list