[CMake] Macro's all and string expansion

[Tristan Carel]

On 9/1/07, Brandon Van Every <bvanevery at gmail.com> wrote:
> On 9/1/07, Tristan Carel <tristan.carel at gmail.com> wrote:
> > Hi,
> >
> > While passing a regular expression to macro as parameter, I
> > experimented strange behaviour:
> >
> > $ cat bar.cmake
> > MACRO(FOO regexp)
> >   IF("foo.bar" MATCHES "${regexp}")
> >     MESSAGE(STATUS "FOO: match")
> >   ENDIF("foo.bar" MATCHES "${regexp}")
> > ENDMACRO(FOO)
> >
> > IF("foo.bar" MATCHES "foo\\.bar")
> >   MESSAGE(STATUS "REFERENCE: OK")
> > ENDIF("foo.bar" MATCHES "foo\\.bar")
> >
> > FOO("foo\\.bar")
> > $
> > $ /usr/bin/cmake --version
> > cmake version 2.4-patch 6
> > $
> > $ cmake -P bar.cmake
> > -- REFERENCE: OK
> > CMake Error: Invalid escape sequence \.
> > CMake Error: Syntax error in cmake code at
> > /tmp/bar.cmake:11:
> > syntax error, unexpected cal_ERROR, expecting $end (5), when parsing
> > string "foo\.bar"
> >
> > I must increase the escape level to make the macro's call working:
> >   FOO("foo\\\\.bar")
> >
> > I want to be able to pass non-tricky regular expressions to macros,
> > firstly because escaping stuff is very annoying and secondly because a
> > user shouldn't need to know macro's internal mechanisms to use it.
> >
> > If it is not a bug, can something clarify this to me?
> > Thx by advance.
>
> This is bug #5389, "MACRO consumes double escapes in string
> arguments."

Oops, didn't see it.

> I discovered it for exactly the same regex processing
> reasons you did.  It is very very annoying when trying to write more
> abstract code.  A workaround is to pass variables instead of strings,
> so that the macro argument reader can't ruin the strings.

Indeed this is quiet critical. Meanwhile, I will use your tip.
Thanks Brandon.

-- 
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
http://www.tristancarel.com