[CMake] lexical scoping

[Brandon Van Every]

On Nov 3, 2007 3:16 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca> 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