[CMake] function and raise_scope commands

[Miguel A. Figueroa-Villanueva]

On Dec 28, 2007 11:36 AM, Ken Martin wrote:
> > > > 1. CMake crashes if I use the same variable name as the argument and
> > > > raise the scope later. That is, for the following function:

<snip>

> Specifically
>
> Variable  value
> --------------------
> is_changed  is_changed
>   set(${is_changed} "some_result")
> is_changed some_result
>   raise_scope(${is_changed})
>
> well this last line becomes raise_scope(some_result) and since there is no
> local variable named some_result it yerks. I have fixed the crash and it now
> prints a nice warning message (on my local copy of cmake, not checked in
> yet) but I'm not sure that is all the solution. I think a safer fix may be
> to change the raise scope command to look like the following:
>
> raise_scope(var_name value var_name value ...)
>
> with a convention that you do not set variables that are to be returned (aka
> passed by reference). In this case that would be is_changed. You leave
> is_changed alone and only use it in the raise scope command. So the
> resulting code would look like.
>
> function(track_find_variable cache_variable is_changed)
>    set(changed "some_result")
>    raise_scope(${is_changed} "${changed}")
> endfunction(track_find_variable)
>
> which is safer. But I am still want to think about it a bit before I commit
> the change.

Well, I think the above is fine, but it's the convention of not using
the variable that is solving the problem not the command syntax. That
is, if you do a set(is_changed ...) before the raise_scope you still
get into trouble.

I think printing a warning when the argument contains the same name as
the variable, and just have the convention of putting an underscore in
front of the argument should work as well:

function(track_find_variable _cache_variable _is_changed)

At least, that is what I'm doing and it is simple to stick to it.

> > 3. I'm having another issue. If you pass a variable to a function that
> > hasn't been defined previously and that isn't defined in the function
> > either, then it crashes when you do a raise_scope on it.
> >
> > For instance, if you have the following function:
>
> Pretty sure I have fixed this on my local copy of the code. I'll check it in
> with the above fixes in a few days (still on vacation for a few more days)

Thanks.

--Miguel