[cmake-developers] Build failed in Jenkins: kdelibs_frameworks_qt5 #1806

[Daniele E. Domenichelli]

Hello Steve,

On 02/12/13 08:23, Stephen Kelly wrote:
> David Faure wrote:
>>> Configure step exited with non-zero code, assuming failure to configure
>>> for project kdelibs. Build step 'Execute shell' marked build as failure
>>
>> Looks like a bug in cmake_next, leading to infinite recursion and
>> therefore a crash.
> 
> Yep. For once, not caused by me :).
> 
> Bisect points to 
> 
> commit bf203c8f8e4a6ad4f642b2653f8abca563484889
> Author: Daniele E. Domenichelli <daniele.domenichelli at iit.it>
> Date:   Thu Nov 14 11:42:35 2013 +0100
> 
>     CMakeParseArguments: Add workaround for compatibility with CMake <= 
> 2.8.12
> 
> Daniele, could you have a look?


I managed to reproduce this even in a smaller test case that does not
use CMakeParseArguments, therefore I assume this might be a bug in CMake...
Please have a look at the unit test I added in the topic macro-scope-test

For some reason a module containing something like

  function(_foo)
    [...]
  endfunction()

  macro(foo)
    _foo()
  endmacro()

will cause an endless loop when calling foo() if the file is included in
2 different scopes.
This seems to happen for any combination of macro and function, but only
if the name of the 2 functions is different only for the initial
underscore (i.e. "foo" and "_foo", but not "foo" and "__foo" or "foo"
and "xfoo").

Do you have any idea about what could be the reason?


I noticed that the "header guard" that is used for CMakeParseArguments,
as well as in several other modules, does not protect the module from
being included in different scope, causing this issue. In the branch, I
replaced it with an if(COMMAND) instead, that works in different scopes,
fixing this issue:

-if(__CMAKE_PARSE_ARGUMENTS_INCLUDED)
+if(COMMAND cmake_parse_arguments)
   return()
 endif()
-set(__CMAKE_PARSE_ARGUMENTS_INCLUDED TRUE)


Does this look acceptable?


Cheers,
 Daniele