Calling autoconf in a spec.

[Sam Varshavchik]

drago01 writes:

> On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane <tgl at redhat.com> 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.
>
> Exactly patching generated code is just wrong period.

Ok, then when you patch configure.in, configure.ac, and/or Makefile.am, be  
sure to also specify:

BuildRequires: autoconf=[version]

and

BuildRequires: automake=[version]

in order to have a reproducible build.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110703/66800563/attachment.bin