Calling autoconf in a spec.

[Sam Varshavchik]

Adam Williamson writes:

> On Sun, 2011-07-03 at 12:48 -0400, Sam Varshavchik wrote:
>
> > 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.
> > Once you understand how autoconf spews out the configure script, and you've
> > looked at a sufficient number of various configure scripts, figuring out  
> how
> > to patch it directly, so it does what you want, is not rocket science.
>
> The problem with doing it that way is that the patch is not
> upstreamable.

Agreed. This is much easier: taking the sledgehammer approach of patching  
the configure script source, regenerating the entire kit and kaboodle, and  
just having a brief runthrough of the end results, only as far as needed to  
conclude that the brand new, rebuilt from scratch, configure /appears/ to  
work. Even though I'm rebuilding the whole scheme, I don't really need to  
know or be familiar with everything that the configure script -- the ones  
that I just rebuilt from scratch -- does. Then, let's just send the same  
patch upstream, and just take this for granted that rerunning the build  
script on top of some unspecified future autoconf, in the future, will  
produce the same results.

I must admit that this is definitely easier that carefully pulling apart the  
configure script itself, and isolating just the one or two lines to be  
patched, usually just something on the order of adding something to PATH, or  
something similar. Although this assures that rerunning the build script, at  
any time in the future, will produce the same results, who cares about that?

Yes -- that's too much work; it's much easier just to assume that always  
regenerating the entire, massive, configure script will always work  
correctly with any future version of autotools, even if I'm not really  
familiar with everything that the configure script does in the first place.

But, personally, I don't mind the extra work, see. I just have this odd idea  
of assigning a somewhat higher priority to having a reproducible build  
script, that produces the same results each and every time. I guess I've  
just been brainwashed by what I need to do during the day, where any kind of  
a change must be vetted, before it gets introduced into a situation where  
unexpected downtime gets very, very costly. But, of course I forget that  
this is not the case here, and if a future version of autoconf breaks  
something, no big deal, and we'll just fix the package when we find it.  
Works for me.

Beside, we also have the "fails-to-build-from-source" report, I think I  
recall seeing something like this recently. This should catch most  
manifestations of this kind of breakage, so rather than avoid breakings  
stuff in the first place, eh, no big deal, let's just save some time and  
worry about it when it breaks. Maybe we'll get lucky, and the FTBS report  
gives an early heads-up on this.

Postscriptum:

I occasionally receive patches to my man pages. Some typos or  
clarifications, or whatnot. But, my man pages are generated from Docbook  
XML, using the Docbook XSLT stylesheets.

The fact that the patch is useless, and I really need one against the XML,  
rather than the generated troff source. If it addresses a real problem, I  
don't care. I don't respond with an arrogant demand to redo the patch  
against the XML source. Sheesh.


-------------- 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/20110704/4c86e507/attachment.bin