autoconf-patches
[Top][All Lists]
Advanced

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

Re: Fix chdir-long.m4 caching


From: Stepan Kasal
Subject: Re: Fix chdir-long.m4 caching
Date: Wed, 27 Sep 2006 19:29:45 +0200
User-agent: Mutt/1.4.2.1i

Hello,

before I said that the check seems OK, I considered briefly the
possibility of passing a macro to AC_CACHE_CHECK.
But I saw that the argument is passed to AS_LITERAL_IF without
an expansion, and that Autoconf itself expands the parameter before
passing it, eg. in AC_CHECK_FUNC:
        AS_VAR_PUSHDEF([ac_var], [ac_cv_func_$1])dnl
        AC_CACHE_CHECK([for $1], ac_var,...)
I just concluded that macros are not allowed in the parameter.

But it shows that this is a real issue.

On Tue, Sep 26, 2006 at 08:03:36PM +0200, Ralf Wildenhues wrote:
> [...] I guess you'd suggest I need to rip
> off a set of `[]' quotes from the second argument of AC_CACHE_CHECK.
> I'd argue that this could be a backward incompatibility for user code.

Well, I'm afraid we need a specification here:
1) what is the right way?
2) which of the cases which happened to work previously should be
maintained?

``The right way'' first.

1a)
I think that it would be best for consistency to write:
  AC_CACHE_CHECK([for $1], [ac_var], ...
and then remove the [] quotes from the definition of AC_CACHE_CHECK.
(Is this the proposal you expected and dismissed? ;-)

I do not think the expansion in
        AS_LITERAL_IF($2,
is too dangerous, I would hope that the parameter does not contain
commas nor that it has some side-effects.

And of the caller passes the parameter expanded, we will expand it
once more; again, I do not think this would cause problems in
practice.

1b)
If we cannot do the above, we can just add a hint to manual, then the
cache-id should be expanded before it is passed to AC_CACHE_CHECK.
Ugly.

2)
Well, in 1a) I explained that I do not expect problems.
If reality differs form my expectations, we can add some
workarounds.  :-)

>  m4_defun([AC_CACHE_VAL],
> -[m4_bmatch([$2], [AC_DEFINE],
> +[AS_LITERAL_IF([$1],
> +  [m4_ifndef([$1],
> +     [m4_bmatch([$1], [_cv_], [],
> +     [AC_DIAGNOSE([syntax],
> +[$0($1, ...): suspicious cache-id, must contain _cv_ to be cached])])])])dnl

Well, I don't think this is safe wrt manros in the cache-id
parameter.  I dug out this from libtool.m4:

AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
  [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)],

The `ifndef' doesn't help here, it is pure luck that it doesn't
trigger the warning.

Indeed, I would use
        AS_LITERAL_IF($1, [m4_bmatch....])
which matches nicely my 1a) proposal.

BTW, this quote from libtool.m4 might serve as an evidence that it is
really natural for macro writers to quite the cache-id parameter,
even when it contains a macro call.

Wdyt?

Have a nice day or two, until I break it again!
        Stepan `reckless' Kasal




reply via email to

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