Re: [CMake] lexical scoping ... back to the future !

[aaron . meadows]

Very fascinating!  I've similarly had to deal with spiraling dependencies in 
our local code.

I had two thoughts toward the problems you mentioned below.  To handle unique 
naming of temporaries, you could do something like introduce a counter 
(probably as a global property) and append it to your variable names.  In 
psuedocode:
   RecursingMacro()
  # Get Global Property=> oNEST
  # Increment Global Property  => iNEST= NEST+1
  # Set Global Property<= iNEST

  # Use for uniqueness

  foreach (depname ${depnames})
  set ( ${depname}_DIR_{$iNEST} ...)
  ...

However, you might not need to do that.  You could use functions and then just 
store your results in global properties, with a list of their names in a known 
property (continuously append the new variable names).  Then at the end of the 
recursive dependency walk, you can import those properties into variables at 
the parent scope.  

Anyway, just a thought..


Aaron Meadows


-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of 
François Mauger
Sent: Thursday, February 23, 2012 6:11 PM
To: Jean-Christophe Fillion-Robin; cmake@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/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 directory or function creates a new scope.
> This command will set the value of a variable into the parent 
> directory or calling function (whichever is applicable to the case at hand)."
>
> I created a small example showing that variable set within a function 
> don't interfere with the parent scope if not explicitly required.
>
> git clone git://gist.github.com/136.git 
> <http://gist.github.com/136.git>
> cmake -P 136/cmake-illustrate-function-scope.cmake
>

Hi JC

I've also played around with functions vs macros to check for scoping features 
and I have basically written the same test script for my own learning. I agree 
that SET coupled with the PARENT_SCOPE directive can solve some scope issues 
within function, preserving the very useful ability to have "pure" local 
variables and still making possible for a given variable to be visible ONE 
scope level up. The problem is when you need to invoke several find_package 
commands from a thread of nested function/macros, eventually with some 
recursive pattern.
AFAIU, a find_package() command implies to be invoked from a macro, and not a 
function, to preserve the global scoping of the xxx_LIBRARIES and 
xxx_INCLUDE_DIRS variables set from a FindXxx.cmake or xxx-config.cmake file, 
and thus make them visible at the top-level CMakeLists.txt file for example.
May be I'm wrong and I miss something but it seems other people, trying to 
setup a set of homemade macros/functions to traverse automatically a dependency 
tree, have also faced this kind of scoping issue.

Because I have to build some complex applications and libraries from a large 
set of "low-level" dedicated home-made libraries that have dependency links 
between them (not cyclic of course, but possibly diamond shaped),  I've 
implemented a basic CMake dependency driver that uses a simple lists of 
dependency rules for any new home-made library (let's call it 'xxx') that 
depends on some other libraries I have at hand.

from the xxx's top-level CMakeLists.txt,  I just have to set:
{{{
SET( xxx_deprules "GSL:>=1.12;Python:>=2.6:<=2.7.3;foo:>=2.1;bar:=3.2" ) }}} 
which means I want to check and use:
- GSL libs with ver >=1.12
- Python (interp+libs) with ver in [2.6-2.7.3]
- my home-made foo lib with ver >=2.1
- my home-made bar with ver==3.2
and then automatically build some xxx_INCLUDE_DIRS and xxx_LIBRARIES from these 
rules.

There is a special set of macros that are given the "xxx_deprules" list and are 
supposed to invoke the 'find_package (...)' command to check if the 
dependencies in the list are fulfilled. Then the macros collect/aggregate the 
various [GSL|Python|foo|bar]_INCLUDE_DIRS and [GSL|Python|foo|bar]_LIBRARIES 
variables. Note that packages like GSL and Python or Boost use typically the 
so-called 'Module' find_package mode (FindGSL, FindPythonInterp, FindBoost...) 
while my foo and bar package uses the 'Config' mode through well-formatted 
foo-config.cmake and bar-config.cmake files.
Note also that because the FindXxx.cmake files provided with the CMake 
distribution does not follow a strict pattern and standard (varia

Re: [CMake] lexical scoping ... back to the future !

[François Mauger]

>>> 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/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 directory or function creates a new scope.
This command will set the value of a variable into the parent directory
or calling function (whichever is applicable to the case at hand)."

I created a small example showing that variable set within a function
don't interfere with the parent scope if not explicitly required.

git clone git://gist.github.com/136.git

cmake -P 136/cmake-illustrate-function-scope.cmake



Hi JC

I've also played around with functions vs macros to check for scoping 
features and I have basically written the same test script for my own
learning. I agree that SET coupled with the PARENT_SCOPE directive can 
solve some scope issues within function, preserving the very useful 
ability to have "pure" local variables and still making possible for a 
given variable to be visible ONE scope level up. The problem is when you 
need to invoke several find_package commands from a thread of nested 
function/macros, eventually with some recursive pattern.
AFAIU, a find_package() command implies to be invoked from a macro, and 
not a function, to preserve the global scoping of the xxx_LIBRARIES and 
xxx_INCLUDE_DIRS variables set from a FindXxx.cmake or xxx-config.cmake 
file, and thus make them visible at the top-level CMakeLists.txt file 
for example.
May be I'm wrong and I miss something but it seems other people, trying 
to setup a set of homemade macros/functions to traverse automatically a 
dependency tree, have also faced this kind of scoping issue.


Because I have to build some complex applications and libraries from
a large set of "low-level" dedicated home-made libraries that have 
dependency links between them (not cyclic of course, but possibly 
diamond shaped),  I've implemented a basic CMake dependency driver that 
uses a simple lists of dependency rules for any new home-made library 
(let's call it 'xxx') that depends on some other libraries I have at hand.


from the xxx's top-level CMakeLists.txt,  I just have to set:
{{{
SET( xxx_deprules "GSL:>=1.12;Python:>=2.6:<=2.7.3;foo:>=2.1;bar:=3.2" )
}}}
which means I want to check and use:
- GSL libs with ver >=1.12
- Python (interp+libs) with ver in [2.6-2.7.3]
- my home-made foo lib with ver >=2.1
- my home-made bar with ver==3.2
and then automatically build some xxx_INCLUDE_DIRS and xxx_LIBRARIES 
from these rules.


There is a special set of macros that are given the "xxx_deprules" list 
and are supposed to invoke the 'find_package (...)' command to check if 
the dependencies in the list are fulfilled. Then the macros 
collect/aggregate the various [GSL|Python|foo|bar]_INCLUDE_DIRS and 
[GSL|Python|foo|bar]_LIBRARIES variables. Note that packages like GSL 
and Python or Boost use typically the so-called 'Module' find_package 
mode (FindGSL, FindPythonInterp, FindBoost...)

while my foo and bar package uses the 'Config' mode through
well-formatted foo-config.cmake and bar-config.cmake files.
Note also that because the FindXxx.cmake files provided with the CMake 
distribution does not follow a strict pattern and standard (variable 
names...), I have to wrap the find Module  within some dedicated macros 
to standardize the output (examples: Boost_VERSION gives "104700" and 
not "1.47.0", argh ! ).


So far, so good. Now assume that the "foo" lib depends also on external 
libs, say : 'john' and 'doe'. because they are also home-made libraries, 
I also provide some  'john-config.cmake' and 'doe-config.cmake' files 
for both.


The dependency check for the 'xxx' lib is implemented in the following way:
0) From the xxx Top-level CmakeLists.txt file, I loop on the list of 
dependecy rules (gsl, python, foo...)

1 ) Example for "foo:>=2.1" : invoke
{{{
find_package (foo 2.1 REQUIRED NO_MODULE HINT ...)
}}}
  this loads the 'foo-config.cmake' file with all
  its exported DLL targets : here the john DLL and the doe DLL
2) because foo has been build with john==1.2 and doe==3.1.4, the 
foo-config.cmake calls explicitely :

{{{
   find_package (john 1.2 EXACT REQUIRED NO_MODULE HINT ...)
}}}
and
{{{
   find_package (doe 3.1.4 EXACT REQUIRED NO_MODULE HINT ...)
}}}
with the consequence that both john-config.cmake and doe-config.cmake
will be sourced with their own exported targets.
3) again if john also depends on other libs (exported targets), the 
process recurses down to the leaf dependency


the result is that, given a simple dependency rule
in the top-level cmake file :
  "GSL:>=1.12 ; Python:>=2.6:<=2.7.3 ; foo:>=2.1 ; bar:=3.2"
we can rebuild the full path of the
depencency tree, including hidden parent dependencies exported target, 
and store 

Re: [CMake] lexical scoping ... back to the future !

[Jean-Christophe Fillion-Robin]

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 directory or function creates a new scope. This
command will set the value of a variable into the parent directory or
calling function (whichever is applicable to the case at hand)."

I created a small example showing that variable set within a function don't
interfere with the parent scope if not explicitly required.

git clone git://gist.github.com/136.git
cmake -P 136/cmake-illustrate-function-scope.cmake

Hth
Jc

On Wed, Feb 22, 2012 at 7:07 PM, François Mauger wrote:

> Hi CMakers,
>
> In november 2007, there was a long thread titled "lexical scoping".
> The discussion was really interesting and was suggesting that some
> "local scoping" features for variables could be implemented in CMake...
> particularly from macros, which are probably the practical case that
> causes most issues when users implement several nested levels of macro
> invocations with many intermediate temporary variables that unfortunately
> aggregate in the global scope. It is really easy to face such problem in a
> rather large project driven with Cmake (a dependency driver invoking the
> find_package command in a foreach loop must be done from a macro AFAIK).
> Unless I missed something in the jungle of CMake threads and doc, I'm
> afraid I was not able to find some satisfactory solution other than hacks
> (using very long variable names to "emulate" some pseudo local scopes).
> this is tedious and bug prone.
>
> Browsing the last 4 years of archives and some additionnal docs, I was not
> able to find a single trace of such new feature : implementing "local
> scoping" in CMake (whatever "local scoping" could rationally mean).
>
> What is the current situation on users' side ? Is there any pressure for
> "local scoping" ? Maybe too few people ask for it so CMake developpers do
> not consider it as a priority... or no clear definition
> of "local scoping" has been patterned ?
> more what is the view of the CMake devel team ? do they consider this idea
> as a good one or not ?
>
> Thanks a lot for hints and advices.
>
> Best regards
> frc
> --
> François Mauger
> LPC Caen-CNRS/IN2P3-UCBN-ENSICAEN
> Département de Physique -- Université de Caen Basse-Normandie
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake
>



-- 
+1 919 869 8849
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Philip Lowman]

-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 variable to maintain complete backwards
>> compatibility.  SETCACHE() could be added to keep things consistent as
>> Brandon suggests.  Trying to make SET be able to set everything is just
>> going to over complicate the command... it's already complicated enough
>> as it is.  What really needs to happen is to break it into three
>> commands: one for globals, one for locals, and one for cache.
>>
>> SETLOCAL() would be used to define local variables that are local to a
>> scoped region.  Scoped regions would include:
> 
> What about functions like STRING() or FILE(READ) which can return values in 
> variables ?

Unless the user has defined a local variable already I would leave
things the way they are and define "global" or "makefile" specific
variables.

For example:

SETLOCAL(uc_name)
STRING(TOUPPER ${name} uc_name)

While this may be a bit cumbersome it seems the easiest way to handle
the problem.


- --
Philip Lowman
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHLlOKe0tOktX6RKkRAoIyAJ90wvQIYqXG2t7SwSgBp7DXj7OxhQCdHcAb
lBV8DsGwSkgNskpBFHkuwck=
=fzM7
-END PGP SIGNATURE-
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Hendrik Sattler]

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 to maintain complete backwards
> > compatibility.  SETCACHE() could be added to keep things consistent as
> > Brandon suggests.  Trying to make SET be able to set everything is just
> > going to over complicate the command... it's already complicated enough
> > as it is.  What really needs to happen is to break it into three
> > commands: one for globals, one for locals, and one for cache.
> >
> > SETLOCAL() would be used to define local variables that are local to a
> > scoped region.  Scoped regions would include:
>
> What about functions like STRING() or FILE(READ) which can return values in
> variables ?

And what about the ability to escape a scope? It doesn't make much sense if 
the only way is to use the global scope for that.
I'd prefer being able to differ between variable declaration and assigning a 
value to a variable.
I'd suggest to keep the current SET syntax unless a variable was declared for 
a specific scope _before_ a SET command, e.g. with
IF(foo)
declare_local(bar)
set(bar "a message")
ENDIF(foo)

The other syntax can stay the same this way (the CACHE keyword should be 
ignored for such cases) and you can easily access the parent scope unless you 
use the same variable name (which is just the same in other programming 
languages).

HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[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 to maintain complete backwards
> compatibility.  SETCACHE() could be added to keep things consistent as
> Brandon suggests.  Trying to make SET be able to set everything is just
> going to over complicate the command... it's already complicated enough
> as it is.  What really needs to happen is to break it into three
> commands: one for globals, one for locals, and one for cache.
>
> SETLOCAL() would be used to define local variables that are local to a
> scoped region.  Scoped regions would include:

What about functions like STRING() or FILE(READ) which can return values in 
variables ?

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Philip Lowman]

-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 added to keep things consistent as
Brandon suggests.  Trying to make SET be able to set everything is just
going to over complicate the command... it's already complicated enough
as it is.  What really needs to happen is to break it into three
commands: one for globals, one for locals, and one for cache.

SETLOCAL() would be used to define local variables that are local to a
scoped region.  Scoped regions would include:
- IF/ELSE/ENDIF scopes
- FOREACH scopes
- WHILE scopes
- MACRO/ENDMACRO scopes

If CMake had a SETLOCAL command it would probably cover 95% of what
people need in terms of being able to create locally scoped variables
and backwards compatibility would be maintained by default.

If someone wanted to add the ability to declare additionally scoped
regions I suppose it could be added for completeness.  I honestly *hate*
the idea of having to maintain a list of scoped variables, however.
Sure it might make implementation easier but it's a hack:

LOCALSCOPE(scope_name var1 var2 var3 var4 var5 var6)
ENDLOCALSCOPE(scope_name)

If arbitrary scoped regions are needed at all it would be far easier
just to rely on something like this:

LOCALSCOPE(scope_name)
ENDLOCALSCOPE(scope_name)

In this case the scope_name really isn't needed at all to implement the
scope but it makes the code easier to read.

Not knowing much about CMake internals I can't estimate how hard it
would be to implement this but it would not be a trivial task.  The
concept of scopes would have to be introduced.  Variable lookup would
have to be able to be done on a stack of scopes.  Scopes would
automatically have to be created and destroyed at various times and the
list of current scopes would have to be in context during all variable
lookups.  If it was done correctly though you would have the exact same
scoping that C/C++, Java, and most other languages currently support.

- --
Philip Lowman
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHLe00e0tOktX6RKkRAhqKAJ0b/0aSyZiZyqoLjVUqXu/PA12JTACeIqDj
2ECmcR/eYj++z2AkCNSnoIg=
=XD/p
-END PGP SIGNATURE-
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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

Re: [CMake] lexical scoping

[Alexander Neundorf]

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 ?
-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 ?
endmacro(m2)


Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 up to now.
>
> Thus, the only completely safe thing to do for backwards compatibility is to
> never use local scope of any kind in the _existing_ modules that have had a
> stable release.  Thus, the only question really is the best way to implement
> scope for new modules (and functions).
>
> If you focus on just that case, then I think the best thing to do is to
> create a command that locally scopes all variables with some mechanism to
> specify the exceptions.

People will also be writing new code that uses old modules.  If you
create a LOCAL scope, and then do something in it with an old module,
that old module is going to break because the behavior of SET has
changed.  I don't think the behavior of SET should change unless the
programmer explicitly asks it to change.

I also think the reality of a build system, is things are more likely
to be global than local.  Those of us implementing new architectonic
capabilities probably lose sight of this fundamental feature of use.
Most people are just trying to build, they're not trying to write
modules.  Looking at my current client's 400MB build tree, there's
almost no substructure to how they did it.  There's 3 layers deep of
IF..ELSE..ENDIF and a lot of calling of standard GMake functions.

Heck, my own super monster translator merely has 1 library of string
utilities, then 1 library of common parsing functions for both
GMakefiles and Bourne shell scripts.  It's far more broad than deep.
It's a big long pipeline of regex upon regex.  I didn't have any
substructure at all until a month into the project.  I deliberately
avoided bothering with it, so that I wouldn't futz with premature API
conventions.  I've just gotten to the point now where there's enough
substructure that scope would be useful and prevent errors.  Hence why
I started this thread.  I was losing actual development time to
shadowing issues; earlier in the project I couldn't say that.

BTW I don't favor putting any kind of extra tags in SET(...) commands.
 If there are going to be tags, don't make them trailing, as in
SET(... LOCAL).  How am I going to know when LOCAL is a tag and when
it is part of my data?  Make it SET(LOCAL ...) if you have to do it.
And strongly consider SETLOCAL, SET_LOCAL, SET_CACHE or whatever.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Alan W. Irwin]

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 used a lot with existing modules that set plenty of 
global variables, and just adding a local_scope around some existing code 
will break it if you make all set's automatically create a new local 
variable.


First, let me say I think adding local scope is a great idea that will make
CMake a much more robust language. Also, it appears the debate is now
between Bill's idea of a command with a specific list of locally scoped
variables or the alternative of a command that locally scopes all variables
with some mechanism to specify the exceptions that have global scope.

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 up to now.

Thus, the only completely safe thing to do for backwards compatibility is to
never use local scope of any kind in the _existing_ modules that have had a
stable release.  Thus, the only question really is the best way to implement
scope for new modules (and functions).

If you focus on just that case, then I think the best thing to do is to
create a command that locally scopes all variables with some mechanism to
specify the exceptions.  The reason I advocate this general approach is I
feel that most variables will be local with some few well-defined
exceptions, and the fewer variables cmake programmers have to type, the less
chance for scope errors in the programming of _future_ CMake macros and
functions.  I think this method of scoping (local scoping with specific
exceptions) is the method used by most languages (with the exception of perl
as you pointed out) for the very reason that the specific exceptions to
locally scoped variables tend to be a much smaller list of variables than
the list of local variables so maintenance issues and scoping bugs are much
reduced by this approach.

My $0.02.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Eric Noulard]

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]>:
>
> The only thing I can think of to make it more pleasant to type (but
> functionally equivalent) is to have it integrate with the
> function/scoped_macro and set commands. Since we now have scope, then
> allow SET(... LOCAL) and have a function command as mentioned before,
> which has an implicit scope declaration.

I agree with that SET( ... LOCAL) would be nice but I would suggest
something more like C++ namespace (without the using keyword)

>
> macro(macro_name ...)
> local(scope_name var1 var2 ... varN)
> 
> endlocal(scope_name)
> endmacro(macro_name)

Why should a scope be "local"
I would rather write

set(scopename:scopedvar )

which will define a variable "scopedvar" in scope "scopename"

the "scopename" may be declared (or not) with
scope(scopename)

you may refer to the variable elsewhere using the scope prefix

set(B ${scopename:scopedvar})

would set the "global" var B to value of the scopevar.

>
> function(macro_name ...)
>   set(var1  LOCAL)
> endfunction(macro_name)
>

Then when you are in a function or macro you always
have a "local" scope at hand thus

set(local:localvar )

means that you use a var 'localvar' in the local scope
which will disappear at the end of function or macro.

In the end if you want to put some var in a scope
you use:

set(:VAR )

in you want to refer to the var

${:VAR}

You may declare as many scope as you want and
you always have:

the global scope:
set(GVAR )   /  ${GVAR}
set(global:GVAR )/  ${global:GVAR}

the local scope is the same as other scopes
but variables used (set or referenced)
in this scope will disappear at the end  of FUNCTION or MACRO
block.

You may want to avoid the scope prefix using

usingscope()

endusingscope()

during which
set(a )
is a synonym of
set(:a value>)
but inside this you must refer/set global variable a with
global:a

Before writing this I've tried (with CMake 2.4.7)

SET(B;A "value")
which seems OK
but
MESSAGE("B:A = ${B:A}")
gives me:
syntax error, unexpected cal_SYMBOL, expecting } (10), when parsing
string "B = ${B:A}"

which makes me think using ":" as scoping operator
may be possible?

-- 
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Miguel A. Figueroa-Villanueva]

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")
> >>> 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)
> >
> > Maybe I'm missing the point, so bare with me...

I new I was missing something ;)

> > I like David's proposal, since it would be the closest to a regular
> > language except that instead of the typical curly braces you have the
> > local/endlocal keywords. Making a function that implicitly creates a
> > scope would avoid the cumbersome typing.
> >
> I guess I think the code would be much clearer if you had to declare a
> variable local.  I think that the convention of any set in a local scope
> creating a new variable would be confusing and cause plenty of errors.
> Remember you can add scope anywhere even around existing stuff.  So lets
> say you have something like this:
>
>
> local_scope()
> 
> set(a "-flag")
> set(CMAKE_CXX_FLAGS ${a} )
> # this is not going to set the variable that everyone expects!
> # it will create a local variable that won't be used at all by the
> # generators.
> end_scope()
>

I guess I'd have to go back to support Bill's idea of having to
declare the variable:

local(scope_name var1 var2 ... varN)
endlocal(scope_name)

The only thing I can think of to make it more pleasant to type (but
functionally equivalent) is to have it integrate with the
function/scoped_macro and set commands. Since we now have scope, then
allow SET(... LOCAL) and have a function command as mentioned before,
which has an implicit scope declaration.

macro(macro_name ...)
local(scope_name var1 var2 ... varN)

endlocal(scope_name)
endmacro(macro_name)

function(macro_name ...)
  set(var1  LOCAL)
endfunction(macro_name)

--Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Bill Hoffman]

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 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)


Maybe I'm missing the point, so bare with me...

I like David's proposal, since it would be the closest to a regular
language except that instead of the typical curly braces you have the
local/endlocal keywords. Making a function that implicitly creates a
scope would avoid the cumbersome typing.



I guess I think the code would be much clearer if you had to declare a 
variable local.  I think that the convention of any set in a local scope 
creating a new variable would be confusing and cause plenty of errors. 
Remember you can add scope anywhere even around existing stuff.  So lets 
say you have something like this:



local_scope()
   
   set(a "-flag")
   set(CMAKE_CXX_FLAGS ${a} )
# this is not going to set the variable that everyone expects!
# it will create a local variable that won't be used at all by the
# generators.
end_scope()

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 used a lot with existing modules that set plenty of 
global variables, and just adding a local_scope around some existing 
code will break it if you make all set's automatically create a new 
local variable.


-Bill

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Miguel A. Figueroa-Villanueva]

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 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)

Maybe I'm missing the point, so bare with me...

I like David's proposal, since it would be the closest to a regular
language except that instead of the typical curly braces you have the
local/endlocal keywords. Making a function that implicitly creates a
scope would avoid the cumbersome typing.

I would think that, in terms of referencing a variable, you would need
to go up in scope until you find the variable if available. The
problem is setting the variable. In this case you do need the
declaration of the variable if you want it in the local scope and it
is already available in a higher level scope. For example,

set(var1 ...) # creates global variable var1
set(var2 ...) # creates global variable var2
local(scope_name)
  set(var1 ...) # create a local variable or set the global variable?
  set(var3 ...) # create local variable var3
  if(var1 ...) ... # depends on the behaviour of set(var1 ...)
  if(var2 ...) ... # access the global variable var2
  if(var3 ...) ... # access the local variable var3
endlocal(scope_name)

The only question mark, from my point of view, is on setting var1. It
seems to me that for that case you have two options:

1. default to creating the local var1 and requiring an escape for
setting the global variable (PARENT_SCOPE, SETGLOBAL, or any other
variation).

2. default to creating everything global and require an escape for
setting the local variable (local(scope_name var1 var2 ... varN),
SETLOCAL, or any other variation). Note that this breaks the intuitive
behaviour above for set(var3 ...).

I prefer the first (1) case. I think it is more popular the case where
you have many local variables and a few relevant global ones, than
viceversa. If this is the case, then the first approach would be less
typing and more intuitive.

In terms of the CACHE, I would consider it the highest level scope and
SET(... CACHE ...) obviously refers to that global scope. Note that
when referencing a local variable that also exists in the CACHE might
create a change in behaviour... I'm not sure what happens currently,
but I think CACHE variables hide regular variables, right?

In any case, I think this discussion is finally leading somewhere!
Creating variable scopes is a quite useful feature.

--Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

re: [CMake] lexical scoping

[Brandon Van Every]

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 declare the variables that are part of the scope.  I
> think you would want to reference and set global variables from within a
> scope.

True.  Must admit my objection_meter goes down now that the reserved
words are much shorter.

> The PARENT_SCOPE maybe needed as well.

Why?  If you have local and global variables in the same scope, you
can set a global variable to the value of a local variable.  You don't
need a PARENT_SCOPE keyword, and you don't need a CACHE keyword.  I
think those keywords are a bad idea as far as making CMake scripting
more likeable.

> local(scope_name var1 var2 ... varN)
>
> endlocal(scope_name)

That would solve some retyping problems.  It's also consistent with
CMake scripting style elsewhere.  I can live with this.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 in the local scope unless
> the "CACHE" arg is used

It does have the advantage that I won't be forgetting to put variable
names in a list.

I'm a little puzzled about CACHE.  The conversion scripts I'm writing
don't even have a cache, they're executed with cmake -P.

> - perhaps a "PARENT_SCOPE" keyword could be used with SET to set something
> back out in the containing scope

Somehow I really hate this nomenclature.  Feels tedious.

> - function would be identical to macro except it would have an implied
> "local"/"endlocal" with the scope_name the same as the function name

Except of course we need to be able to SET the arguments.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Bill Hoffman]

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)


-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[David Cole]

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 local scope would made only in the local scope unless
the "CACHE" arg is used
- perhaps a "PARENT_SCOPE" keyword could be used with SET to set something
back out in the containing scope
- function would be identical to macro except it would have an implied
"local"/"endlocal" with the scope_name the same as the function name
- it would be nice for functions to have an easy to use return value


On 11/3/07, Miguel A. Figueroa-Villanueva <[EMAIL PROTECTED]> wrote:
>
> On 11/3/07, Alexander Neundorf wrote:
> > On Friday 02 November 2007, KSpam wrote:
> > > 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
> > > > # [...]
> > > > variable_scope_end(scratch_preamble)
> > > > variable_scope_end(got_match)
> > > > variable_scope_end(not_trail)
> > > > variable_scope_end(empty)
> > >
> > > would reduce to:
> > >
> > >   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)
> >
> > How about naming it "declare_local_vars()" or just "local()"
> > instead of variable_scope_begin() and have it end always at endmacro() ?
>
> I like both alternative names better, but can't rely on endmacro() for
> ending since this causes an unnecessary limitation. That is, you'd
> want to use this in FindXXX.cmake modules and other scripts not only
> macros.
>
> --Miguel
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Miguel A. Figueroa-Villanueva]

On 11/3/07, Alexander Neundorf wrote:
> On Friday 02 November 2007, KSpam wrote:
> > 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
> > > # [...]
> > > variable_scope_end(scratch_preamble)
> > > variable_scope_end(got_match)
> > > variable_scope_end(not_trail)
> > > variable_scope_end(empty)
> >
> > would reduce to:
> >
> >   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)
>
> How about naming it "declare_local_vars()" or just "local()"
> instead of variable_scope_begin() and have it end always at endmacro() ?

I like both alternative names better, but can't rely on endmacro() for
ending since this causes an unnecessary limitation. That is, you'd
want to use this in FindXXX.cmake modules and other scripts not only
macros.

--Miguel
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Alexander Neundorf]

On Friday 02 November 2007, KSpam wrote:
> 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
> > # [...]
> > variable_scope_end(scratch_preamble)
> > variable_scope_end(got_match)
> > variable_scope_end(not_trail)
> > variable_scope_end(empty)
>
> would reduce to:
>
>   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)

How about naming it "declare_local_vars()" or just "local()" 
instead of variable_scope_begin() and have it end always at endmacro() ?

Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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
> unfortunately use quite often).

and variable_scope(blah1 blah2 blah3) { } sure smells like a hack.
That was my point.  But if you want to point me towards a popular
language community that does such a thing, feel free.  Or an unpopular
language community, if they have any aesthetic merits to argue.  I'm
leery of trying to "educate" new users about why they should have to
type such things though.  I'd almost prefer to tell them to type long
variable name prefixes, because it's probably easier for them to
accept.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

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 than implementing functions?

I never claimed that it would be better than implementing functions.  For that 
matter, I do not think they would be mutually exclusive.  If changes are 
going to be made, it would benefit us all to consider many alternatives.  
There are pros/cons to each approach.

The nice thing about variable_scope is that it gives you more flexibility for 
the variable within a file, macro, or function.  It allows you to layer 
scopes on top of each other.  You get a nice "stack" of values for a 
particular variable name depending on scope.  This can be a very powerful 
construct, and it allows for recursion.  Furthermore, variable_scope and 
functions are orthogonal features.  I would personally like the synergy that 
comes from having both constructs at my disposal.

On the other hand "SETLOCAL" might be a bit easier for a novice to use.

> > I will trade typing a few more characters for variable safety any day.
>
> You can do that now with verbose variable prefixes.

Ah ... you can do ANYTHING if you are willing to sweat hard enough.  You could 
generate your CMake environment from Python (done that) ... you could write 
macros upon macros (done that) ... you could even create custom CMake plugins 
(done that) ...

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 
unfortunately use quite often).

Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 what happens when I change my variable names and
forget to update this stuff?

> 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 than implementing functions?

> I will trade typing a few more characters for variable safety any day.

You can do that now with verbose variable prefixes.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

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
> # [...]
> variable_scope_end(scratch_preamble)
> variable_scope_end(got_match)
> variable_scope_end(not_trail)
> variable_scope_end(empty)

would reduce to:

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)

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
# [...]
}

I think that looks pretty good.  Even without the braces, the construct is 
optional, and it provides a significant improvement in variable safety.  I 
will trade typing a few more characters for variable safety any day.

Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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.  It would certainly be a step in 
> > the
> > right direction, especially if it is easy enough to implement.  [...]
> > The whole "begin ... end" construct gets to be tedious after a while.
>
> Once it's introduced, we're gonna get stuck with it.  Please don't
> just do what's expedient.  Do something that will increase the
> likeability of CMake.

Oh, and I don't want macros that provide scope for only 1 variable at
a time.  When I write a macro that's really supposed to be a function,
I've got lotsa variables that I don't want the outside world to see.
This ain't gonna happen in the real world:

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
# [...]
variable_scope_end(scratch_preamble)
variable_scope_end(got_match)
variable_scope_end(not_trail)
variable_scope_end(empty)

This is also leaving out the issue of whether macro argument names can
shadow each other.  I haven't really investigated that yet.  If they
can, then that's even more scopes to cook up.

The cure is no better than the disease.  I'm already using
splitonlastword_ disambiguators.  In a short function, I'd still be
typing a similar number of extra characters and it would still be a
PITA.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 enough to implement.  [...]
> The whole "begin ... end" construct gets to be tedious after a while.

Once it's introduced, we're gonna get stuck with it.  Please don't
just do what's expedient.  Do something that will increase the
likeability of CMake.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

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" declarations are still ingrained in my head ... try 
writing a large set of PERL scripts without "use strict" and "my" :-)

It sure would be nice if there were more standard ways to denote scope though.  
The whole "begin ... end" construct gets to be tedious after a while.  I am a 
big fan of curly braces ( { ... } ) personally, although I am sure that this 
would require quite a bit more work to the CMake scripting language.

With a construct to control variable scope and curly braces to 
replace "begin ... end", I would be quite satisfied with CMake scripting :-)

Thanks,
Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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.  Possibly at some point in the future I'll
be in a position to comment on whether Lua is "worth it."  The
potential to sell game console developers on $$ build systems is
not lost on me.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Juan Sanchez]

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 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 to work
> around the issue at present.  I already know how to do that, and the
> point is, it's a PITA.  The more PITA in CMake, the slower the
> adoption rate.
> 
> 
> Cheers,
> Brandon Van Every


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 to work
around the issue at present.  I already know how to do that, and the
point is, it's a PITA.  The more PITA in CMake, the slower the
adoption rate.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Juan Sanchez]

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 underneath.

Juan

Brandon Van Every wrote:
> 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 about Perl, as far as I'm concerned they're nobody.  ;-)  Lotsa
>>> people program with functions and would expect a scripting language to
>>> have functions.  Minimize the number of "CMake specific weird things"
>>> people have to learn, if you want more users.  SETLOCAL is not so
>>> objectionable, didn't some Unix shells have this historically?
>>>
>> The problem is what does SETLOCAL mean?   There is no scope in cmake
>> right now.  So, I guess you are saying add functions.
> 
> Yep.
> 
>> I am not even
>> sure what those will be...  Many languages have the idea of scope.
>> Braces in C++.   This would just be a way of creating scope.
> 
> Then add braces.  Not some begin_long_thing_word end_long_thing_word.
> Nobody does that, nobody will like it.
> 
> 
> Cheers,
> Brandon Van Every
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
> 
> 


-- 
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395


___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 directly in strings.  A lot of my
translation code is lifting those things out of their strings and
putting them on previous lines.  Translations would be easier if
people could just do what they're used to doing, in some analogous
manner.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 about Perl, as far as I'm concerned they're nobody.  ;-)  Lotsa
> > people program with functions and would expect a scripting language to
> > have functions.  Minimize the number of "CMake specific weird things"
> > people have to learn, if you want more users.  SETLOCAL is not so
> > objectionable, didn't some Unix shells have this historically?
> >
> The problem is what does SETLOCAL mean?   There is no scope in cmake
> right now.  So, I guess you are saying add functions.

Yep.

> I am not even
> sure what those will be...  Many languages have the idea of scope.
> Braces in C++.   This would just be a way of creating scope.

Then add braces.  Not some begin_long_thing_word end_long_thing_word.
Nobody does that, nobody will like it.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Bill Hoffman]

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 program with functions and would expect a scripting language to
have functions.  Minimize the number of "CMake specific weird things"
people have to learn, if you want more users.  SETLOCAL is not so
objectionable, didn't some Unix shells have this historically?

The problem is what does SETLOCAL mean?   There is no scope in cmake 
right now.  So, I guess you are saying add functions.  I am not even 
sure what those will be...  Many languages have the idea of scope. 
Braces in C++.   This would just be a way of creating scope.



-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 would expect a scripting language to
have functions.  Minimize the number of "CMake specific weird things"
people have to learn, if you want more users.  SETLOCAL is not so
objectionable, didn't some Unix shells have this historically?


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Bill Hoffman]

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 
cmake without having to create the idea of a function.  You could of 
course pass in a list of variables to variable_scope. It would be sort 
of like the "my" in perl.   I don't think it would be that hard to 
implement this, and it would be backwards compatible, and not make the 
set command any more complicated.  You could nest them as well.  It 
could cause some odd things to happen if you forgot to add the 
scope_end, but it might fix more things than it breaks.


-Bill



___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

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 setting of the variable
> 4) they can be access globally using get_directory_property and specifying
> the directory etc

I do like the effect of "cascading" variables down the CMakeLists.txt 
hierarchical structure.  This is very handy.  Of course, for variables that 
are not required to be passed down the chain, this is a maintenance headache.  
IMHO, your solution of adding functions would resolve much of this headache.

> 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 no inherent scope they are just string replacements,
> functions do have scope built in). With a function command we could
> probably figure out some way to create variables that are scoped to the
> function only. Most of the places we are using macros really could/should
> be functions. My main question would be if we had a function, how would you
> want variables handled.

I agree that most macros would be better suited as functions.  I am certain 
that this is the case for my projects.  I would suspect that 80% of my macros 
should really be functions.

> 1) all set commands create "local" variables to the function (a mess for
> functions that do an include of other cmake code)
> 2) a special set command or signature that creates a local variable scoped
> to the current function
> 3) a mode to switch the behavior of set (yuck)
> 4) something else

My vote would be for 2.  I like to be able to grep my CMakeLists.txt files.  
Having two set commands (or signatures) would ease the task of grepping 
for "global" vs. local variables.  This would also make it easy to set either 
type of variable in a function definition.

Thanks,
Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[Brandon Van Every]

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 no inherent scope they are just string replacements, functions
> do have scope built in). With a function command we could probably figure
> out some way to create variables that are scoped to the function only. Most
> of the places we are using macros really could/should be functions.

Yes please!  95% of MACROs I've written are really trying to be functions.

> My main
> question would be if we had a function, how would you want variables
> handled.
>
> 1) all set commands create "local" variables to the function (a mess for
> functions that do an include of other cmake code)
> 2) a special set command or signature that creates a local variable scoped
> to the current function

SET and SETLOCAL is one possibility.  I could live with it.
SET and SETGLOBAL is another possibility.  It would require breaking
backwards compatibility.

> 3) a mode to switch the behavior of set (yuck)

No.  For stability of developing a build system, that's completely ridiculous.


Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

RE: [CMake] lexical scoping

[Ken Martin]

Variables can be a PITA :) They have unusual scoping, mixed documentation,
etc. In CVS there have been some changes. We have extended the concept of
properties which are scoped to an object (source file, target, directory,
global, test, for example) and are documented, can be inherited, and can be
tested to verify they are documented. This is nice and meets some needs of
CMake. But ... there are still variables.  Recently Bill and I have started
documenting variables in the source code (cmake --help-variables works) such
that you can get documentation on supported variables in cmake. These
documented variables are the ones we will try to keep backwards compatible
(tm), all others are up in the air.

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 setting of the variable
4) they can be access globally using get_directory_property and specifying
the directory etc

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 no inherent scope they are just string replacements, functions
do have scope built in). With a function command we could probably figure
out some way to create variables that are scoped to the function only. Most
of the places we are using macros really could/should be functions. My main
question would be if we had a function, how would you want variables
handled.

1) all set commands create "local" variables to the function (a mess for
functions that do an include of other cmake code)
2) a special set command or signature that creates a local variable scoped
to the current function
3) a mode to switch the behavior of set (yuck)
4) something else

Ken

Ken Martin PhD 
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971 
 

> -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 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 for any mid to large scale project.  Life in the 
> CMake scripting 
> language would be so much nicer if we could scope variables 
> at the macro 
> and/or file level.
> 
> Justin
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] lexical scoping

[KSpam]

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 for any mid to large scale project.  Life in the CMake scripting 
language would be so much nicer if we could scope variables at the macro 
and/or file level.

Justin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake