[CMake] Plans for extending CMake language?

[David Cole]

I feel the growing pains just within a project sometimes...... For example,
having a macro with a local looping variable simply named "i" is problematic
if you make it a habit. As soon as you call macro2 that also uses a variable
"i" from inside your loop in macro1, the behavior is not quite what you
expected.

On 7/27/07, Christian Convey <christian.convey at gmail.com> wrote:
>
> 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.
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20070728/05fef598/attachment.html