[CMake] Plans for extending CMake language?

[Brandon Van Every]

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.

> - I wrote a helper macro that probably shouldn't be considered part of
> my package's interface.

I'm not up on that kind of issue.  In practice, if it's not documented
in cmake.html then who's gonna know?

> So my question is: are there any plans to enhance CMake's language so
> that it better supports modularity, black box (or at least grey box)
> implementations of packages, etc.?

I have no idea.  These aren't issues that trouble me.  Are any of them
going to really really break something, if the module author knows
what she's doing?

The issue that does trouble me, is that macros consume double escapes
in string arguments.  See bug #5389.  I can't pass regexp strings
around because of this.  Lotsa other dangerous behavior can come of
it.


Cheers,
Brandon Van Every