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