@cmake.org
Subject: Re: [CMake] lexical scoping ... back to the future !
On 23/02/2012 02:00, Jean-Christophe Fillion-Robin wrote:
Hi François,
Would the use of function be helpful ?
See
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:function
and http://www.cmake.org/cmake/help
Hi François,
Would the use of function be helpful ?
See http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:function
and http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set
If PARENT_SCOPE is present, the variable will be set in the scope above
the current scope. Each new
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
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)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brandon Van Every wrote:
And strongly consider SETLOCAL, SET_LOCAL, SET_CACHE or whatever.
Absolutely. Here's what I would recommend...
SET() should always set a global variable to maintain complete backwards
compatibility. SETCACHE() could be
On Sunday 04 November 2007, Philip Lowman wrote:
Brandon Van Every wrote:
And strongly consider SETLOCAL, SET_LOCAL, SET_CACHE or whatever.
Absolutely. Here's what I would recommend...
SET() should always set a global variable to maintain complete backwards
compatibility. SETCACHE()
Am Sonntag 04 November 2007 schrieb Alexander Neundorf:
On Sunday 04 November 2007, Philip Lowman wrote:
Brandon Van Every wrote:
And strongly consider SETLOCAL, SET_LOCAL, SET_CACHE or whatever.
Absolutely. Here's what I would recommend...
SET() should always set a global variable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alexander Neundorf wrote:
On Sunday 04 November 2007, Philip Lowman wrote:
Brandon Van Every wrote:
And strongly consider SETLOCAL, SET_LOCAL, SET_CACHE or whatever.
Absolutely. Here's what I would recommend...
SET() should always set a global
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)
function(fname same args as macro)
endfunction(fname)
- local/endlocal pairs should be nestable
- any SET within the
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
On Nov 3, 2007 10:42 AM, David Cole [EMAIL PROTECTED] 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)
- any SET within the local scope would made only
On Nov 3, 2007 11:13 AM, Bill Hoffman [EMAIL PROTECTED] 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
On 11/3/07, 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
Miguel A. Figueroa-Villanueva wrote:
On 11/3/07, 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
On 11/3/07, Bill Hoffman wrote:
Miguel A. Figueroa-Villanueva wrote:
On 11/3/07, 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)
I'm taking this thread after some hours away from computer.
I read the whole thread (without missing someything I hope)
and the scoping name feature seems interesting.
I have some more ideas on syntax and keyword name
keep reading...
2007/11/3, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED]:
On 2007-11-03 12:27-0400 Bill Hoffman wrote:
Declaring a variable as local is done in perl. Which had the same sort of
problem. By default all variables in perl are global. You have to put a
my in front of the variable to specifically ask it to be a local variable.
I think this will be
On Nov 3, 2007 3:16 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
Bill, I can see why you are worried about breaking existing modules where
you are not sure of what macro variable have been used by some users and
what has not, but in fact you cannot tell how CMake users have used macro
variables
On Friday 02 November 2007 09:54:51 Brandon Van Every wrote:
Is it feasible to modify the CMake language to have lexical scoping?
I agree. The lack of variable scoping is currently my biggest annoyance with
custom macros. Additionally, I believe that custom macros are pretty much
required
On Nov 2, 2007 2:26 PM, Ken Martin [EMAIL PROTECTED] wrote:
the macro command is like a cpp macro so scoping does not make a lot of
sense for it. What would/could make sense is a function command that creates
a function. (think of the difference in a macro versus a function in c,
macros have
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of KSpam
Sent: Friday, November 02, 2007 1:32 PM
To: cmake@cmake.org
Subject: Re: [CMake] lexical scoping
On Friday 02 November 2007 09:54:51 Brandon Van Every wrote:
Is it feasible to modify the CMake
I have an idea. What if we created a variable_scope command?
Something like this:
set(a world)
variable_scope_begin(a)
set(a hello)
message(${a})
variable_scope_end(a)
message(${a})
The above would print out:
hello
world
This could be done with the current macros, or even an include file of
Ken,
But to the question at hand...adding scope to variables. Variables have
scope right now of
1) the CMakeListfile they are defined in
2) any included files that are included after the variable is set
3) and subdirectories of the directory they were defined in and processed
after the
On Nov 2, 2007 3:44 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
I have an idea. What if we created a variable_scope command?
Bad markerting idea. Nobody programs in this idiom. (Well, I don't
know about Perl, as far as I'm concerned they're nobody. ;-) Lotsa
people program with functions and
Brandon Van Every wrote:
On Nov 2, 2007 3:44 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
I have an idea. What if we created a variable_scope command?
Bad markerting idea. Nobody programs in this idiom. (Well, I don't
know about Perl, as far as I'm concerned they're nobody. ;-) Lotsa
people
On Nov 2, 2007 4:13 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
Brandon Van Every wrote:
On Nov 2, 2007 3:44 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
I have an idea. What if we created a variable_scope command?
Bad markerting idea. Nobody programs in this idiom. (Well, I don't
know
On Nov 2, 2007 2:39 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
SET and SETLOCAL is one possibility. I could live with it.
While we're at it, how difficult would it be for functions to return a
value that can be used in other contexts? GMake has $(whatever ...)
functions that can be used
My suggestion as a temporary work around would be to apply a namespace
prefix to the variables in your macro.
Create the macro with short variable names x.
Test
Replace variable names with uniques ones MACRO_DOIT_x
Release
If included in another file, your users don't have to see the munged
code
On Nov 2, 2007 4:22 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
My suggestion as a temporary work around would be to apply a namespace
prefix to the variables in your macro.
That's what my example is. I even pointed out the naming policy I
use. I want to talk about making things better, not how
Oh,
I guess you did. My apologies.
I guess the best way to fix your issue would be to move to a lua frontend.
Juan
Brandon Van Every wrote:
On Nov 2, 2007 4:22 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
My suggestion as a temporary work around would be to apply a namespace
prefix to the
On Nov 2, 2007 4:34 PM, Juan Sanchez [EMAIL PROTECTED] wrote:
I guess the best way to fix your issue would be to move to a lua frontend.
It's a way. Another way is to add functions to CMake script.
I've started looking at Lua games on Sourceforge, as an excuse to
learn something about it.
Bill,
set(a world)
variable_scope_begin(a)
set(a hello)
message(${a})
variable_scope_end(a)
message(${a})
This would be a workable solution for me. It would certainly be a step in the
right direction, especially if it is easy enough to implement. I was into
PERL years ago, so my
On Nov 2, 2007 5:02 PM, KSpam [EMAIL PROTECTED] wrote:
Bill,
set(a world)
variable_scope_begin(a)
set(a hello)
message(${a})
variable_scope_end(a)
message(${a})
This would be a workable solution for me. It would certainly be a step in the
right direction, especially if it is easy
On Nov 2, 2007 5:08 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Nov 2, 2007 5:02 PM, KSpam [EMAIL PROTECTED] wrote:
Bill,
set(a world)
variable_scope_begin(a)
set(a hello)
message(${a})
variable_scope_end(a)
message(${a})
This would be a workable solution for me.
Brandon,
You missed the part where Bill mentioned that variable_scope would take
multiple arguments. Your example:
variable_scope_begin(scratch_preamble)
variable_scope_begin(got_match)
variable_scope_begin(not_trail)
variable_scope_begin(empty)
# [...]
# my actual code, blah blah blah
On Nov 2, 2007 5:57 PM, KSpam [EMAIL PROTECTED] wrote:
variable_scope_begin(scratch_preamble got_match not_trail empty)
# [...]
# my actual code, blah blah blah
# [...]
variable_scope_end(scratch_preamble got_match not_trail empty)
That's better, but
Brandon,
Of course, if we could get braces into the mix, it would reduce to:
variable_scope(scratch_preamble got_match not_trail empty)
{
# [...]
# my actual code, blah blah blah
# [...]
}
Why is this better
On Nov 2, 2007 6:51 PM, Justin C. Keesling [EMAIL PROTECTED] wrote:
The bottom line is not what is possible, but rather how can we make this build
system easier to use, more flexible, and more powerful without users having
to resort to hacks. Verbose variable prefixes is a hack (one that I
38 matches
Mail list logo
