an update to automake-1.11?
Sam Varshavchik
mrsam at courier-mta.com
Thu Jul 9 01:42:27 UTC 2009
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090708/93090c88/attachment.sig>
More information about the fedora-devel-list
mailing list