On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote: > Richard W.M. Jones writes: > > On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: > >> What line number changes? You cut a patch against configure, and you're > >> done. That's it. > > > > And you get a big patch containing line numbers. Here's a single line > > change to configure.ac, and the corresponding patch that generates: > ====================== > > Who said anything about patching configure.ac? The cited link is not a patch > to the configure script, it's a result of a patch to configure.ac. > > I'll repeat again: patch configure, not configure.ac. > > I said "patch configure", and you reply, "well, it won't work because if you > patch configure.ac, run autoconf, then generate the patch between the > original configure, and the new configure, I get a big hairball". Duh. The fundamental problem with patching configure instead of configure.ac (or Makefile instead of Makefile.am) is that it's changing the wrong semantic level. As a bad example (because sed would be a better tool), imagine a patch to Makefile that does basically s/-O2/-Os/g. Now upstream makes a new release, and adds a new build target. Your patch might still apply, but it'll miss the CFLAGS emitted for the new target, and your patch will no longer _mean_ the same thing it used to. This is the same reason we patch .c files, and not the intermediate .i or .S. Don't let the fact that you never see the intermediate files in the tarball confuse you. You don't see them because they're not abstraction levels humans should have to deal with; and neither is the complete expanded configure script. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
