Variable scoping (was Re: [CMake] CMake with Lua Experiment)

Pau Garcia i Quiles pgquiles at elpauer.org
Wed Nov 28 05:36:13 EST 2007


Quoting Brandon Van Every <bvanevery at gmail.com>:

> On Nov 28, 2007 3:40 AM, Pau Garcia i Quiles <pgquiles at elpauer.org> wrote:
>>
>> Do you mean these threads?
>> http://www.cmake.org/pipermail/cmake/2005-March/006235.html
>> http://www.cmake.org/pipermail/cmake/2005-June/006725.html
>
> "These are not the threads you're looking for."
>
>> If you are talking about a different thread, could you
>> please tell me which one?
>
> "lexical scoping"
> http://public.kitware.com/pipermail/cmake/2007-November/017385.html
>
> Must say, I couldn't find this by using the Kitware mailing list
> search engine on the keywords "lexical scoping."  Most baffling since
> it's the subject line.

Wow. I did not read a single message in that thread. I would have  
suggested inlining the scope of the variable in the variable name,  
like Ruby does, instead of SET, SET(LOCAL ...), VARIABLE_SCOPE, etc:

* variable => local variable
* @variable => instance variable
* @@variable => class variable
* $variable => global variable
* VARIABLE => constant

Of course it would be different in CMake. Here comes a quick'n'dirty proposal:

* variable => global variable (keep compatibility with CMake 2.4)
* @variable => local variable (for example, inside a macro, if, foreach, etc)
* @@variable => module (= file) variable (for instance, for  
FindXXXX.cmake modules). It does not exist outside the current file  
(even INCLUDE'ing a file which defines @@variable would NOT make  
@@variable available outside the file which defined it).
* VARIABLE => constants defined by modules (FindXXXX.cmake), cannot be  
changed after setting it (this way it's impossible to accidentally  
modify for example QT_LIBRARIES in a CMakeLists.txt)

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)



More information about the CMake mailing list