2011/11/13 Michael Hertling <[email protected]>:
[...]
> Sorry, I talked nonsense in my previous reply. Obviously, the line
>
> IF("${VARIABLE}" MATCHES "^${VARIABLE}$")
>
> serves to prevent the macro's re-execution if the result variable is
> already defined, i.e. if the macro has most certainly been called
> before with the same parameters. E.g., with VARIABLE equaling
> "HAVE_XYZ_H", this line expands to
>
> IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
>
> and due to the implicit evaluation of variables on the left-hand
> side of the IF() command's MATCHES clause, it finally looks like
>
> IF(TRUE MATCHES ^HAVE_XYZ_H$)
>
> or
>
> IF(FALSE MATCHES ^HAVE_XYZ_H$)
>
> provided the macro has been called before, i.e. HAVE_XYZ_H is either
> TRUE or FALSE. Of course, these latter conditions are false, so the
> macro isn't executed again. OTOH, if the variable HAVE_XYZ_H is un-
> defined, i.e. the macro has not been called yet, the line remains
>
> IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
>
> which is true, so the macro is executed. Therefore, the macro is
> skipped if the result variable indicates that there is already a
> result. Thus, in contrast to what I erroneously said before, one
> can indeed "define" a header as working by presetting the result
> variable to TRUE, and one can not re-use the same result variable
> for different calls to CHECK_INCLUDE_FILES(). In order to revisit
> your question, a failing
>
> IF("${VARIABLE}" MATCHES "^${VARIABLE}$")
>
> means that VARIABLE denotes another variable which has already been
> defined. If this doesn't explain your findings away, please come up
> with a small but complete example which demonstrates the issue for
> further investigation.
>
> BTW, IF("${VARIABLE}" MATCHES "^${VARIABLE}$") is not bullet-proof,
> IMO: If VARIABLE denotes another variable which has its own name as
> value, the MATCHES condition always evaluates to true. Instead, one
> should use IF(NOT DEFINED "${VARIABLE}") - with the quotes, this is
> always evaluating to the intended result, AFAICS. Eric, what's your
> opinion?
I think your analysis is right "DEFINED" is the safest way to verify a previous
var definitiion, however may be the current module was written before
DEFINED existed.
An example of non-bullet proofness using Michael idea is attached.
try
cmake -P matchName.cmake
and toggle the commented line at the top of the file.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
set(MYVAR "MYVAR")
# toggle this to see the difference
#set(MYVAR "WHATEVER")
set(VARIABLE MYVAR)
if (NOT DEFINED "${VARIABLE}")
message("${VARIABLE} is NOT defined (DEFINED method)")
else()
message("${VARIABLE} is defined (DEFINED method)")
endif()
if("${VARIABLE}" MATCHES "^${VARIABLE}$")
message("${VARIABLE} is NOT defined (MATCHES method)")
else()
message("${VARIABLE} is defined (MATCHES method)")
endif()
--
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
