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.
I've been reading configure scripts long enough to know that your pseudo-patch is the result of adding AC_PATH_PROG(PERL, perl) to configure.ac.
Now, why don't you explain why, and we'll go from there. Presuming that this is needed because some script in $srcdir uses the PERL environment variable, or a later part of the configure script itself (it assumes that PERL is set in the environment) then I would just patch in:
PERL=/usr/bin/perl export PERLinstead, to configure. Or, have the spec file set PERL itself, before running configure. If the reason for the patch is that there's some *.in in src with a @PERL@ placeholder, I'd just patch that *.in file directly, instead.
No need to uselessly screw around with configure, when I don't even need to do it.
Like I said earlier, there seems to be a meme going around that making a minor fix to configure is an impossible task. It can't be done, the only option is to fix configure.ac, and rerun autoconf. configure itself is untouchable. You can't patch it, you have to patch configure.ac, and then regenerate it.
Description: PGP signature