Calling autoconf in a spec.

[Nils Philippsen]

On Sun, 2011-07-03 at 13:31 -0400, Tom Lane wrote:
> Sam Varshavchik <mrsam at courier-mta.com> writes:
> > To add to that: I never recall a single instance where I couldn't fix any  
> > breakage in someone else's canned configure/makefile scripts without having  
> > to rerun autoconf and automake.
> 
> > If there was a problem in the configure script, rather than patching  
> > configure.ac or configure.in, I simply patched the configure script itself.  
> 
> Yeah, and the question is why that's a good idea at all, let alone so
> superior as to be policy.  To me it sounds exactly like arguing that you
> should fix a code bug by patching the emitted assembler code, instead of
> touching the C code.  Or fixing a grammar problem by patching bison's
> output file instead of the input .y file.  It just seems uselessly stone
> age.  And it certainly does not yield a patch that you are going to be
> able to submit to upstream.

Here's my 2 cents: I just change things in Makefile.am, configure.ac,
etc. -- making changes upstreamable -- then run autoreconf and generate
a patch that brings the original configure, Makefile.in, etc. files to
the state I got after running autoreconf -- which makes builds (better)
repeatable.

I'd really love to be able to re-run current auto-tools on old
Makefile.am/configure.{in,ac} files and the results to work in all
cases, but right now that seems utopian to me.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011