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.
Attachment:
pgpkw0iLNae5V.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
