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