Created attachment 62764 [details] CMake with macros that crashes KDevelop Version: 4.2.3 (using KDE 4.7.0) OS: Linux I have this CMakeLists.txt (in attachments) with two recursive macros that do some directory traversing. When importing a new project with it, it goes in a infinite recursive loop. Its not clear to me why this happens, I didn't wrote this file but it works ok with CMake, whereas kdevelop crash. If I remove the lines where those macros are called, it loads fine the project but the macros are needed. The full project is git://gitorious.org/~leonardo2d/siege/leonardo2ds-siege.git. Reproducible: Always Steps to Reproduce: Import a new CMake Project with recursive macros like ones in attachment. Actual Results: KDevelop crashes after a infinite loop Expected Results: KDevelop import the project.
Ok, I decided to understand the macros and found that FILE(GLOB files RELATIVE ${srcDir} ${srcDir}/*) returns nothing on ${files}, as if ${srcDir} was empty. It isn't, so I assume this is intended behaviour, but then, below, there is a FOREACH(file ${files}) and there's where the problem happens. It shouldn't enter in this FOREACH because ${files} is supposed to be empty. Inside that foreach, in SET(srcPath ${srcDir}/${file}) SET(destPath ${destDir}/${file}) srcPath becomes the original ${srcDir} with a / appended to it. IF(NOT IS_DIRECTORY ${srcPath}) CONFIGURE_FILE(${srcPath} ${destPath} COPYONLY) ELSE(NOT IS_DIRECTORY ${srcPath}) CONFIGURE_FILES(${srcPath} ${destPath}) ENDIF(NOT IS_DIRECTORY ${srcPath}) it always go into that else because ${srcPath} is a directory, a valid one because a lot of / appended in the end of the directory still makes it valid. And then it calls CONFIGURE_FILES, the same macro, creating the infinite loop. Something is wrong here, either FILE returning empty list of files or the foreach looping in a empty variable. Those macros works ok in CMake.
I cloned the repo and loaded the project without issue. Did you remove the offending cmakelists section? If so, could you provide an example cmakelists with the issue?
I changed the cmake in that repository so Kdevelop could load it, but replacing the top-level CMakeFile.txt with the one provided in the attachment should exhibit the bug.
imo cmake should guard against accidental infinite recursions anyways: put this into a CMakeLists.txt: macro(foo) foo() endmacro(foo) foo() => crashes KDevelop.
Well... we can make it possible to cancel the project importing... I don't think it's that easy to check if it's an infinite recursion...
Thank you for the report. As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!