Kevin Kofler writes:
Sam Varshavchik wrote:In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case.That's one project. It doesn't prove any sort of a general trend.
That's one more project's worth of data that you posted yourself.
I invite you to find a counterexample, but I regret to inform you, finding one won't be easy.I already mentioned a bunch of counterexamples (all the stuff I worked on with Romain Liévin: tfdocgen, libticables2, libticonv, libtifiles2, libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.).
Rattling off a bunch of project names is a poor substitute for posting two years' worth of data.
Why don't you grab the last one or two years' worth of these projects' releases, and see how many releases had updated configure.ac scripts, and how many releases were rebased to newer versions of autoconf.
You know, like what I did, for openldap.But, I'm pretty sure I know what you'll expect to find. And you know the same thing, too. And which is why you don't want to do it.
Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf.You just found one project which is extremely reluctant to upgrade their autoconf (and it's one of those projects still using the deprecated "configure.in" file name, that says pretty much everything).
No, it means that there is absolutely no reason to rename a file, just for the heck of it. Whether it's configure.in or configure.ac, it's irrelevant. Or, perhaps, you'd like to explain the major difference between naming the source file for autoconf as configure.in, or configure.ac.
And I didn't really do much of finding, as I said. It's one of the packages that I'm tracking on http://manpages.courier-mta.org which has the largest archive of historical releases. But, you're demanding to look at some project that uses configure.ac?
Sure. Not that it makes one fig's worth of difference, of course, whether it's configure.in or configure.ac, but here you go: pcre. It's another one that I'm tracking. Upstream only has the last four releases available, but they also span about a year and a half chronologically, rougly the same time span as openldap:
pcre-7.6/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.6. pcre-7.7/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.7. pcre-7.8/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.8. pcre-7.9/configure:# Generated by GNU Autoconf 2.63 for PCRE 7.9.Looking at pcre's configure.acs, only pcre-7.8 had no substantive changes from the previous version, all the others contained very major changes. Looks like this one doesn't agree with your theory, too.
So go ahead, and tell me again how that's still insufficient data for your liking (all the while offering zilch of hard data yourself, I note). I'll be happy to continue, as long as you like, but, you must understand, the hits will just keep on comin'.
I also snuck a peek at the evolution of GnuTLS's toolchain. I guessed that it would be your best hope of salvaging some crumb of hard data that goes your way -- given that it's a GNU project and thus would be the most likely ones to always rebase to the latest-and-greatest autotools.
Well, I looked at it, and would you like to see how GnuTLS's version history actually is? I'll be happy to post it. All you have to do is ask.
Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update.I'm ignoring your example because it's one example against 9+ examples from me,
You did not post a single example. Rattling off names of packages is not the same thing as actually listing which version of autoconf generated each version, and how many original changes went into the corresponding configure.in (or configure.ac), thus giving you an actual look at what the rate of change is to configure.ac, versus the rate of change to the version of autotools that generated the configure script. Why don't you do that, and really prove how wrong I am?
Attachment:
pgpfonKKgIkrc.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
