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 <[EMAIL PROTECTED]> wrote: > > On 7/27/07, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > On 7/27/07, Christian Convey <[EMAIL PROTECTED]> 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 > [email protected] > http://www.cmake.org/mailman/listinfo/cmake >
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
