[CMake] lexical scoping

[Brandon Van Every]

On Nov 4, 2007 5:10 AM, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
> On Saturday 03 November 2007, Bill Hoffman wrote:
> > David Cole wrote:
> > > After all the discussion / suggestions that have been part of this
> > > thread, I like the following best:
> > >
> > > local(scope_name)
> > >   set(var1 "value1")
> > >   set(var2 "value2")
> > > endlocal(scope_name)
> >
> > I would prefer to declare the variables that are part of the scope.  I
> > think you would want to reference and set global variables from within a
> > scope.  The PARENT_SCOPE maybe needed as well.
> >
> > local(scope_name var1 var2 ... varN)
> >
> > endlocal(scope_name)
>
> I like that.
> Three questions:
> -why is a scopename required ?

For one thing it's parallel with IF..ELSE..ENDIF..ENDFOREACH..ENDMACRO
names being repeated.  If the scope has to be closed in the same way
as those constructs, then it could be "relaxed" by the same mechanism
that IF..ELSE..ENDIF can currently be relaxed.  On the other hand, if
the scope doesn't have to be closed in quite such a neat and orderly
manner, if it can have extent quite a bit farther into the file, then
perhaps interesting things can be done.  Another question is whether
the scope_name can be decided dynamically, i.e. could I conditionally
choose which scope to end?

> -will local variables be "inherited" to called macros ?
> -will they be "inherited" to included cmake files ?
>
> I.e. how will this behave:
>
> set(foo "foo")
>
> macro(m1)
>   set(foo "bar")
> endmacro(m1)
>
> macro(m2)
>   local(myscope foo)
>   set(foo "localfoo") # global foo unchanged
>   m1()              # will m1 change the global foo or the local one from m1 ?
     endlocal(myscope)  # let's not assume a macro ends a scope
> endmacro(m2)

m1 changes the local foo only.  I see no other possible
interpretation.  Seems perfectly reasonable to me, it's what the
programmer asked for.  The programmer only wants the results of the
macro m1() to apply within the local scope.

The difficulty is merely that library routines shouldn't produce
global side effects unless such side effects are well documented.  If
there are docs, and the programmer doesn't read them, that's his
fault.


Cheers,
Brandon Van Every