[CMake] Fwd: [CMake 0012398]: "IF" infamous <variable/string> functionality fails to work with macro arguments

[David Cole]

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
======================================================================