[CMake] Plans for extending CMake language?

[Christian Convey]

On 7/27/07, Brandon Van Every <bvanevery at gmail.com> wrote:
> On 7/27/07, Christian Convey <christian.convey at gmail.com> wrote:
> > I'm working on my first CMake package, an came across a few things
> > that concerned me:
> >
> > - My package uses variables from the same namespace that all other
> > CMake code uses.  To avoid unintended variable/macro name conflicts,
> > I'm forced to use long variable names.
>
> So?  What's so different about tacking your library name in front of a
> variable, and tacking a namespace in front of your variable?  The user
> is going to use the namespaces to disambiguate when he uses multiple
> modules, i.e. he'll always have to do it.
>
> > - There's no notion (that I can see) of local variables whose scope is
> > only limited to within a Macro.
>
> Well the arguments have local scope, so that's some insurance.  Guess
> you'd better initialize your other local variables.  Taking away the
> ability to operate on global variables would be bad.  I have lotsa
> macros whose sole purpose is to cut down the amount of typing of the
> same variables I know I'll be using throughout CMakeLists.txt over and
> over again.

Any point-by-point arguments I'd make would be pretty much redundant
to the arguments for encapsulation that have been developed over the
last 30+ years.

As far as hiding helper macros by not documenting them, that's a
start, but there's still the issue of a global namespace that becomes
increasingly congested as more and more packages are developed.

Also, enforcing explicit interfaces to packages can reduce the problem
of a package being reliant on the value of a variable but not saying
so in its doc, or setting a variable that has an unintended effect on
code outside of the module.

Note that I'm *not* saying that CMake's language sucks and *needs* to
be replaced.  I'm not that naive (anymore).

I'm was just asking if people have started to see growing pains as
more and more modules get added to CMake, and thought about ways to
control the complexity by extending the scripting lanugage.