[CMake] Issue with check_include_file() and GL/glxproto.h

[Eric Noulard]

2011/11/13 Michael Hertling <mhertling at online.de>:
[...]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: matchName.cmake
Type: text/x-cmake
Size: 427 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111113/612e3908/attachment.bin>