[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: avoiding undesired macro expansion after AS_TR_CPP
From: |
Bruno Haible |
Subject: |
Re: avoiding undesired macro expansion after AS_TR_CPP |
Date: |
Fri, 4 Jun 2010 01:59:13 +0200 |
User-agent: |
KMail/1.9.9 |
Hi Eric,
> On the other hand, why not use:
>
> AM_CONDITIONAL(AS_TR_CPP([[LIBUNISTRING_$1]]), [true])
Yes, I'm using this trick now.
> >> AM_CONDITIONAL([LIBUNISTRING_]AS_TR_CPP([[$1]]), [true])
> AM_CONDITIONAL(AS_TR_CPP([[LIBUNISTRING_$1]]), [true])
You seem to insist that the problem is with the _argument_ of AS_TR_CPP.
If I write
AS_TR_CPP([[libunistring_foo_bar]]
this might well help to avoid unwanted expansion of the argument (the
lowercase string). But my problem is with the _result_ of AS_TR_CPP, the
uppercase string.
As an autoconf user, I would find it very strange and surprising to have
to add quoting inside the arguments of a macro call when I want to avoid
expansion of the result. I understand that macros like AC_LANG_SOURCE
require double quoting because the user may want to have macro invocations
in parts of the arguments and no accidental macro invocations in other
parts of the arguments. This is all about the arguments...
Bruno