[CMake] Bug in macro command

[Moreland, Kenneth]

> > 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?

Comment: I actually have run into a situation where this would have been
quite useful.  Of course, it's more important Filipe's example works,
but just wanted to chime in that the new functionality is not without
merit.

On a side note, I got around the problem by implementing a CMake version
of Tcl's upvar.  The idea is to promote the name of a variable to a
usable variable.  It was a simple one line macro:

MACRO(UPVAR varname outvar)
  SET(${outvar} ${${varname}})
ENDMACRO(UPVAR)

So in your example above, the same result could be achieved (in theory)
with

SET(A v)
SET(B ar)
UPVAR(${A}${B} C)
MESSAGE("${C} is var")

I say in theory because the macro can only dereference global variables.
In your example var is a local variable and therefore cannot be
referenced by another macro. (The upvar approach only worked for me
because I happened to be accessing global variables).  Anyway, my point
is that a built-in UPVAR that worked within the local scope would be
helpful in lieu of (or in addition to) the more flexible variable
referencing.

-Ken

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********  
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      fax:   (505) 845-0833