Thanks, Michael... I'll give this another week or so here on the mailing list (and in the bug tracker) to gather feedback.
If I don't hear anything else, I'll consider changing some documentation to clarify the existing situation, but I don't see a reasonable way to accommodate this feature request *and* maintain backwards compatibility with existing real world uses of macro and if commands. David C. On Sat, Aug 13, 2011 at 3:39 AM, Michael Wild <them...@gmail.com> wrote: > For most users, macros should be a taboo anyways. They are much better > served by functions, IMHO. In all of my projects I had only one case > where I actually needed a macro. That was when I wrapped a function > that set some variables in the PARENT_SCOPE and I had to propagate them > outside of the wrapping macro without knowing their name. > > Perhaps it would be enough to just properly document the quirky > behaviour of macro arguments in the docs and mention that one should > normally prefer functions over macros unless there is a real reason > that requires a macro? > > Michael > > > On Fri 12 Aug 2011 09:29:21 PM CEST, David Cole wrote: >> Does anybody here on the list have an opinion one way or the other on >> whether it's worth pursuing a fix to this re-opened bug regarding >> CMake "macro" and "if" command behavior...? >> >> Thanks for any input, either here on the list, or directly in the bug >> notes themselves. >> >> >> Thanks, >> David >> >> >> >> ---------- Forwarded message ---------- >> From: Mantis Bug Tracker <man...@public.kitware.com> >> Date: Fri, Aug 12, 2011 at 2:49 PM >> Subject: [CMake 0012398]: "IF" infamous <variable/string> >> functionality fails to work with macro arguments >> To: david.c...@kitware.com >> >> >> >> The following issue has been REOPENED. >> ====================================================================== >> http://public.kitware.com/Bug/view.php?id=12398 >> ====================================================================== >> Reported By: freddie >> Assigned To: David Cole >> ====================================================================== >> Project: CMake >> Issue ID: 12398 >> Category: CMake >> Reproducibility: always >> Severity: major >> Priority: normal >> Status: feedback >> ====================================================================== >> Date Submitted: 2011-08-12 08:13 EDT >> Last Modified: 2011-08-12 14:49 EDT >> ====================================================================== >> Summary: "IF" infamous <variable/string> functionality >> fails >> to work with macro arguments >> Description: >> There is a problem with the "IF" command when it is used directly with macro >> arguments. Apparently, they are not considered variables and are used >> directly >> as strings. >> >> However, if their contents can be construed as variables themselves (even >> though >> it is not desired), we have a problem when the only way to perform the test >> is >> to create another explicit variable assigning it to what the macro argument >> contains. >> >> The problem doesn't appear to pertain to functions. >> >> Steps to Reproduce: >> Please use the attached CMakeLists.txt file with "cmake -Wno-dev .". >> >> Additional Information: >> It would really be a good idea to create a version of if/elseif/else/endif >> which >> does NOT attempt to treat its arguments as variables, either by creating a >> new >> name for the command or, better yet, by adding a new policy (possibly not >> associated with a version yet). >> >> Otherwise, when trying to compare things which might be variables but should >> not >> be treated as such for the purposes of the comparison, one runs into subtle >> problems (when checks "randomly" fail) or has to create a level of >> indirection, >> by setting a new variable just for that. >> >> I am sure you've heard this all before. >> ====================================================================== >> Relationships ID Summary >> ---------------------------------------------------------------------- >> duplicate of 0009590 IF(VARIABLE) doesn't work inside Makro >> ====================================================================== >> >> ---------------------------------------------------------------------- >> (0027199) freddie (reporter) - 2011-08-12 14:49 >> http://public.kitware.com/Bug/view.php?id=12398#c27199 >> ---------------------------------------------------------------------- >> Your comparison of macro with preprocessor macros makes sense. If only it >> worked >> that way. In cmake language, ${foo} expands a variable; if ARGV0 is not a >> variable, then you must either substitute ARGV0 for what was specified in the >> parameter list for the macro, or use a different expansion {#{ARGV0}, for >> instance); otherwise, people who can't be called stupid will keep running >> into >> these problems. >> >> However, the analogy stops there; FUNCTION is not equivalent to functions or >> methods in C/C++ in the sense that variables are automatically local to the >> function, and setting a variable in a different scope is problematic. If I >> have >> a directory-specific variable that I set and append to in multiple places >> (I'd >> call it namespace-specific), I can't use it here because it's hard to say how >> many parent-scope levels up it is. So we end up using macros. >> >> And about IF: I am not sure about this "worth the effort" statement. This >> behaviour is quite unusual (I don't know of any other language that does >> this) >> and, as it turns out, extremely inconvenient; forget that, after reading the >> manual on IF and MACRO (and the IF epilogue) several times, I still ran into >> problems as described in this bug. What about making it impossible to use the >> macro arguments with IF completely and calling it a feature? Making it easy >> to >> work with cmake and avoid peculiar bugs is probably more important. >> >> ---------------------------------------------------------------------- >> (0027198) David Cole (manager) - 2011-08-12 10:36 >> http://public.kitware.com/Bug/view.php?id=12398#c27198 >> ---------------------------------------------------------------------- >> You're right... we've heard it before. :-) >> >> It would be possible to change this via a cmake policy, but I'm not sure it's >> worth the effort. >> >> Think of CMake macro expansion as analogous to C preprocessor #define macro >> expansion. The "arguments" to: >> >> #define m(x, y, z) ((x) < (y)) ? (z) : 0 >> >> are not C "variables", but that does not mean that such a construct is >> useless... >> >> Similarly with CMake macros: the macro arguments are not "variables" but they >> are still useful to eliminate duplication when used appropriately. >> >> As you've noted functions do have "real variables" as their arguments. >> >> Use function if you need variables. If you must use a macro, and you must >> have >> CMake variables, then you must make the CMake variables with set, as you've >> noted... >> >> Issue History >> Date Modified Username Field Change >> ====================================================================== >> 2011-08-12 08:13 freddie New Issue >> 2011-08-12 08:13 freddie File Added: CMakeLists.txt >> 2011-08-12 10:30 David Cole Assigned To => David Cole >> 2011-08-12 10:30 David Cole Status new => assigned >> 2011-08-12 10:36 David Cole Note Added: 0027198 >> 2011-08-12 10:36 David Cole Relationship added duplicate of 0009590 >> 2011-08-12 10:36 David Cole Status assigned => resolved >> 2011-08-12 10:36 David Cole Fixed in Version => CMake 2.8.6 >> 2011-08-12 10:36 David Cole Resolution open => duplicate >> 2011-08-12 14:49 freddie Note Added: 0027199 >> 2011-08-12 14:49 freddie Status resolved => feedback >> 2011-08-12 14:49 freddie Resolution duplicate => >> reopened >> ====================================================================== >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/listinfo/cmake > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake