[CMake] Bug in macro command

[Ken Martin]

> Subject: [CMake] Bug in macro command
> 
> The following code displays
> --
> -- xxx
> -- Configuring done
> -- Generating done
> 
> instead of
> -- xxx
> -- xxx
> -- Configuring done
> -- Generating done
> 
> MACRO(foo var)
>   SET(${var} "xxx")
> ENDMACRO(foo)
> 
> foo(var)
> MESSAGE(STATUS ${var})
> 
> foo(hello)
> MESSAGE(STATUS ${hello})

Hmmm, very interesting. Here is what is going on. The original MacroCommand
did a simple string replacement on its arguments and ARGV ARGC etc. So in
the above example:  SET (${var} "xxx")  would get sent to the parser as: SET
(var "xxx") in the first call. In the new implementation the formal
arguments and ARGC ARGV etc are set as variables that are expanded like any
other variable. To be safe I restore any variables set by the macro command
to their original value at the end of the macro execution. So.. in your
example you happen to be setting a formal argument to a new value in your
macro command AND the invocation of the macro is passing in a variable with
the same name as the formal argument. So the macro sets var to xxx and at
the end of the invocation the macro command sets it back to its original
value. This doesn't happen for the second invocation because you are passing
hello in.

(whew)

So, I'm thinking of reverting back to the original implementation. The only
advantage of the new implementation (other than shorter code) is that you
can do something like

MACRO(foo var)
  SET (A v)
  SET (B ar)
  MESSAGE ("${${A}${B}} is var")
ENDMACRO(foo)

And ${A} and ${B} will expand to var and then ${var} will expand to whatever
the formal argument to the macro was. Not a very useful feature and not a
traditional behavior of a macro in the C/C++ concept of a macro. Any
comments?

Thanks
Ken