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 <[email protected]> Date: Fri, Aug 12, 2011 at 2:49 PM Subject: [CMake 0012398]: "IF" infamous <variable/string> functionality fails to work with macro arguments To: [email protected] 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
