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. > - 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 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
