an update to automake-1.11?

[Sam Varshavchik]

Kevin Kofler writes:

> Sam Varshavchik wrote:
>> Wrong, as usual.
> 
> That's an ad hominem "argument".
> 
>> Since each autoconf macro typically expands out to hundreds lines of
>> shellcode,
> 
> But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or 
> aclocal version!

You're changing the topic.

On this point, we're not talking about what happens when autoconf changes. 
Here, the original statement was that patches to configure.ac are less 
likely to be kicked out than configure, if configure.ac changes.

I pointed out that this is completely absurd, and you have no idea how 
autoconf works. You have no answer, so you must now start talking about what 
happens when autoconf itself changes.


>> with the autoconf macro's parameter embedded somewhere in the
>> middle of all that stuff, were you to change a parameter to an autoconf
>> macro in configure.ac, and upstream changes the parameter in the next
>> line, your patch gets broken.
> 
> Upstream is much less likely to change that parameter in the next line than 
> to use a different version of autoconf.

Do you have any data to back up this interesting notion -- that most changes 
to configure are due to autoconf version changes, rather than upstream 
making changes to configure.ac itself?

I thought not.

>> Yes, tell me again how conflicting patches to neighboring lines in
>> configure.ac "works", while the equivalent two patches hundreds of lines
>> apart in configure do not.
> 
> You don't understand me, I'm telling you how patches to configure.ac in an 
> area upstream is unlikely to touch any time soon work, while the equivalent 
> patches in configure get fuzzed by unrelated changes introduced by a new 
> autoconf used by upstream and break.

This is absurd. configure.ac changes due to natural evolution of the 
package far more often than autoconf itself changing.

In fact, many actually loathe switching to a different version of autoconf, 
preferring to stay on the same version as long as possible.

>> Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode,
>> with the arguments to AC_PATH_PROG appearing once, in the middle of them.
> 
> But those "several dozens lines of canned shellcode" CHANGE WITH THE 
> AUTOCONF VERSION!

Which happens far less often than routine changes to configure.ac, as the 
package natural evolves over time. autoconf changes happens maybe once every 
other year or so. Most configure script change far more often than once 
every other year.

This is a bogus argument.

>> Changing the parameter to AC_PATH_PROG, for example, does not change
>> hundreds of lines of shellcode.
> 
> No, but using the next point release of autoconf, even with no changes to 
> configure.ac at all, does.
> 
> Most programmers use fast-moving distros. Distros like Fedora, Debian 

It would be trivial to pick a typical package, and look at intervening 
releases, years apart, and observe the major differences in configure.ac, 
yet, perhaps only one, if none, update to autoconf itself occuring in all 
the intervening releases.

But, once I do that, you'll abandon this reasoning too, once you realize 
that it's a non-starter, and change the topic to something else. It'll 
probably be line number changes.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090708/a5ed22b8/attachment.bin