[CMake] Fwd: [CMake 0012398]: "IF" infamous <variable/string> functionality fails to work with macro arguments
Michael Wild
themiwi at gmail.com
Sat Aug 13 03:39:09 EDT 2011
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 <mantis at 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.cole at 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
More information about the CMake
mailing list