|
Notes |
|
|
(0037275)
|
|
Brad King
|
|
2014-11-25 09:31
|
|
|
Please provide a code example demonstrating the problem. |
|
|
|
(0037288)
|
|
zezadas
|
|
2014-11-26 04:17
|
|
using for example, gwenview from kde
https://projects.kde.org/projects/kde/kdegraphics/gwenview/repository [^]
the file lib/CMakeList.txt
file(READ "${JPEG_INCLUDE_DIR}/jpeglib.h" jpeglib_h_content)
string(REGEX MATCH "#define +JPEG_LIB_VERSION +([0-9]+)" "\\1" jpeglib_version "${jpeglib_h_content}")
set(jpeglib_version ${CMAKE_MATCH_1})
if ("${jpeglib_version}" STREQUAL "")
when the cmake gets to "if ("${jpeglib_version}" STREQUAL "")" jpeg has last ${CMAKE_MATCH_1}, which is 2060 from lcms CMakeList
In the end, the produced result is jpeglib version being 2060, which is not correct.
2060 is the version of lcms, which has been regex match successful before.
http://paste.kde.org/pcoqp2tgq [^] |
|
|
|
(0037296)
|
|
Brad King
|
|
2014-11-26 10:13
|
|
|
|
|
(0037298)
|
|
Ben Boeckel
|
|
2014-11-26 11:38
|
|
Well, first of all, that code has something wrong with it. Did you mean to use string(REGEX REPLACE) rather than string(REGEX MATCH) (though I see upstream has the same problem)? Second of all, I am unable to reproduce using this case with either v3.0.2 or master as of today:
========
if ("01" MATCHES "(0)(1)")
message("CMAKE_MATCH_0: ${CMAKE_MATCH_0}")
message("CMAKE_MATCH_1: ${CMAKE_MATCH_1}")
message("CMAKE_MATCH_2: ${CMAKE_MATCH_2}")
endif ()
string(REGEX MATCH "(0)(1)" output "12")
message("CMAKE_MATCH_0: ${CMAKE_MATCH_0}")
message("CMAKE_MATCH_1: ${CMAKE_MATCH_1}")
message("CMAKE_MATCH_2: ${CMAKE_MATCH_2}")
if ("12" MATCHES "(0)(1)")
else ()
message("CMAKE_MATCH_0: ${CMAKE_MATCH_0}")
message("CMAKE_MATCH_1: ${CMAKE_MATCH_1}")
message("CMAKE_MATCH_2: ${CMAKE_MATCH_2}")
endif ()
========
both versions output:
========
CMAKE_MATCH_0: 01
CMAKE_MATCH_1: 0
CMAKE_MATCH_2: 1
CMAKE_MATCH_0:
CMAKE_MATCH_1:
CMAKE_MATCH_2:
CMAKE_MATCH_0:
CMAKE_MATCH_1:
CMAKE_MATCH_2:
========
Even doing a split over a subdirectory doesn't show the bug.
I think this is a logic error at a minimum because I don't think that the given snippet does what is intended *anyways*. Looking into what is causing the gwenview error. |
|
|
|
(0037299)
|
|
Ben Boeckel
|
|
2014-11-26 11:54
|
|
|
So it appears as though the problem is through AddSubDirectory which finds its way calling down to cmLocalGenerator::SetGlobalGenerator which makes a new cmMakefile not attached to the parent scope's cmMakefile which loses the tracking of how many match items to clear. |
|
|
|
(0037300)
|
|
Ben Boeckel
|
|
2014-11-26 12:56
|
|
|
I've pushed a revert of the branch to revert-cached-regex-clear on the stage. I have a testcase and fix for the original optimization ready for next once release is remerged into master with the revert. |
|
|
|
(0037301)
|
|
Brad King
|
|
2014-11-26 13:57
|
|
|
|
|
(0037323)
|
|
Brad King
|
|
2014-12-01 09:14
|
|
|
Re 0015261:0037301: I've queued the revert for inclusion in the next 3.1 release candidate. |
|
|
|
(0038683)
|
|
Robert Maynard
|
|
2015-05-04 09:05
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|