[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix chdir-long.m4 caching

From: Eric Blake
Subject: Re: Fix chdir-long.m4 caching
Date: Sat, 30 Sep 2006 07:59:15 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060909 Thunderbird/ Mnenhy/

Hash: SHA1

According to Stepan Kasal on 9/29/2006 8:46 AM:
> So I did the one line change to AS_LITERAL_IF, did many changes in
> the indirect callers of it, and wrote a test case.
> The resulting patch is attached here.

Thanks for all that effort.  I agree with your reasoning and testing
approach, and the patch appears to be correct to me.  Is there any
documentation we need to update as a result, just in case there is a rare
compatibility problem?  And I would feel comfortable getting more than
just my opinion before applying this patch, as it touches a rather
fundamental low-level piece of autoconf.

> Can this bring some backward compatibility problems?

Perhaps if the macro has side-effects, although that is bad style:
m4_define([count], [0])
m4_define([ac_var], [m4_pushdef([count],

# this would only bump count once, since we did the expansion early
AC_CACHE_CHECK([for something], ac_var)
# but how many times is count bumped here?  I think it is different pre-
# and post-patch, because the text ac_var gets output multiple times,
# and each output is then expanded during rescanning.
AC_CACHE_CHECK([for something else], [ac_var])

But I don't see any evidence of real-life autoconf macros this perverted,
where the user cares about the final value of count.

> As I said before, I hope the problems should be rare.

I hope so too.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]