On Nov 4, 2007 5:10 AM, Alexander Neundorf <[EMAIL PROTECTED]> 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 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake