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.
<br><br><div><span class="gmail_quote">On 7/27/07, <b class="gmail_sendername">Christian Convey</b> <<a href="mailto:christian.convey@gmail.com">christian.convey@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 7/27/07, Brandon Van Every <<a href="mailto:bvanevery@gmail.com">bvanevery@gmail.com</a>> wrote:<br>> On 7/27/07, Christian Convey <<a href="mailto:christian.convey@gmail.com">christian.convey@gmail.com</a>
> wrote:<br>> > I'm working on my first CMake package, an came across a few things<br>> > that concerned me:<br>> ><br>> > - My package uses variables from the same namespace that all other<br>
> > CMake code uses. To avoid unintended variable/macro name conflicts,<br>> > I'm forced to use long variable names.<br>><br>> So? What's so different about tacking your library name in front of a
<br>> variable, and tacking a namespace in front of your variable? The user<br>> is going to use the namespaces to disambiguate when he uses multiple<br>> modules, i.e. he'll always have to do it.<br>><br>
> > - There's no notion (that I can see) of local variables whose scope is<br>> > only limited to within a Macro.<br>><br>> Well the arguments have local scope, so that's some insurance. Guess<br>
> you'd better initialize your other local variables. Taking away the<br>> ability to operate on global variables would be bad. I have lotsa<br>> macros whose sole purpose is to cut down the amount of typing of the
<br>> same variables I know I'll be using throughout CMakeLists.txt over and<br>> over again.<br><br>Any point-by-point arguments I'd make would be pretty much redundant<br>to the arguments for encapsulation that have been developed over the
<br>last 30+ years.<br><br>As far as hiding helper macros by not documenting them, that's a<br>start, but there's still the issue of a global namespace that becomes<br>increasingly congested as more and more packages are developed.
<br><br>Also, enforcing explicit interfaces to packages can reduce the problem<br>of a package being reliant on the value of a variable but not saying<br>so in its doc, or setting a variable that has an unintended effect on
<br>code outside of the module.<br><br>Note that I'm *not* saying that CMake's language sucks and *needs* to<br>be replaced. I'm not that naive (anymore).<br><br>I'm was just asking if people have started to see growing pains as
<br>more and more modules get added to CMake, and thought about ways to<br>control the complexity by extending the scripting lanugage.<br>_______________________________________________<br>CMake mailing list<br><a href="mailto:CMake@cmake.org">
CMake@cmake.org</a><br><a href="http://www.cmake.org/mailman/listinfo/cmake">http://www.cmake.org/mailman/listinfo/cmake</a><br></blockquote></div><br>