Re: Fix chdir-long.m4 caching

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
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],
  m4_incr(count))ac_cv_side_effect_counter])

# 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFHngz84KuGfSFAYARAlioAKCBpFh888t3g6a+G/F0gNSlc3DTegCfeLod
85eGSQvji/ITXDnrcxEe4rU=
=2m/E
-----END PGP SIGNATURE-----