[CMake] Fwd: [CMake 0012398]: "IF" infamous <variable/string> functionality fails to work with macro arguments
David Cole
david.cole at kitware.com
Mon Aug 15 11:26:19 EDT 2011
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 <themiwi at 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 <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
>
>
> _______________________________________________
> 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