[Top][All Lists]
[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
- Re: Fix chdir-long.m4 caching, (continued)
- Re: Fix chdir-long.m4 caching, Ralf Wildenhues, 2006/09/26
- Re: Fix chdir-long.m4 caching, Eric Blake, 2006/09/26
- Re: Fix chdir-long.m4 caching, Stepan Kasal, 2006/09/26
- Re: Fix chdir-long.m4 caching, Ralf Wildenhues, 2006/09/26
- Re: Fix chdir-long.m4 caching, Eric Blake-1, 2006/09/26
- Re: Fix chdir-long.m4 caching, Eric Blake, 2006/09/26
- Re: Fix chdir-long.m4 caching, Ralf Wildenhues, 2006/09/27
- Re: Fix chdir-long.m4 caching, Eric Blake-1, 2006/09/27
- Re: Fix chdir-long.m4 caching, Stepan Kasal, 2006/09/29
- Re: Fix chdir-long.m4 caching, Eric Blake, 2006/09/30
- Re: Fix chdir-long.m4 caching,
Stepan Kasal <=
- Re: Fix chdir-long.m4 caching, Stepan Kasal, 2006/09/29
- Re: Fix chdir-long.m4 caching, Eric Blake, 2006/09/30