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

[David Cole]

Moving forward, with new code, we should always use if(DEFINED) or
if(NOT DEFINED) constructs. They should largely be equivalent, except
for edge/corner cases you've noted involving variables whose values
are other variable names.

The construct found in lines such as:
IF("${VARIABLE}" MATCHES "^${VARIABLE}$")

are leftovers from the days pre-dating the availability of using
if(DEFINED).... They still work, so we leave them the same in most
cases for exact backwards compatibility. If we were to write that code
today, we would, of course, use if(NOT DEFINED) instead.


Thx,
David


On Sun, Nov 13, 2011 at 4:25 AM, Eric Noulard <eric.noulard at gmail.com> wrote:
> 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
>
> --
>
> 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
>