View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015261CMake(No Category)public2014-11-24 07:582015-05-04 09:05
Reporterzezadas 
Assigned ToBen Boeckel 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSlinuxOS Version
Product Version 
Target VersionCMake 3.1Fixed in VersionCMake 3.1 
Summary0015261: regex match when not matched do not clear cmake_match_0 and 1 var
Descriptionwhen regex match is not matched the var are not reseted, and keep the last value, that bug propagates to other cmake and generate bad regex match
Steps To Reproduceregex match something that exists
regex match something that not exists
regex match value, is the first match value
Additional Informationfor example compiling gwenview from kde repo, it says that jpeglib as unknown version 2060, but in this case the file it searched not matched the regexp and the 2060 is from another cmakte that match version of lcms
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0037275)
Brad King (manager)
2014-11-25 09:31

Please provide a code example demonstrating the problem.
(0037288)
zezadas (reporter)
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 (manager)
2014-11-26 10:13

This was likely regressed by this optimization:

 ClearMatches: Only clear matches which were actually set
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f718b30a [^]
(0037298)
Ben Boeckel (developer)
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 (developer)
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 (developer)
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 (manager)
2014-11-26 13:57

Re 0015261:0037300: I revised the commit message, started a second branch to hold a merge resolving conflicts with 'master', and merged to 'next' for testing:

 Revert "ClearMatches: Only clear matches which were actually set"
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d674b5f [^]

 Merge branch 'revert-cached-regex-clear' into revert-cached-regex-clear-for-master
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=808c77e2 [^]
(0037323)
Brad King (manager)
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 (manager)
2015-05-04 09:05

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2014-11-24 07:58 zezadas New Issue
2014-11-25 09:31 Brad King Note Added: 0037275
2014-11-26 04:17 zezadas Note Added: 0037288
2014-11-26 10:13 Brad King Note Added: 0037296
2014-11-26 10:14 Brad King Assigned To => Ben Boeckel
2014-11-26 10:14 Brad King Status new => assigned
2014-11-26 10:14 Brad King Target Version => CMake 3.1
2014-11-26 11:38 Ben Boeckel Note Added: 0037298
2014-11-26 11:54 Ben Boeckel Note Added: 0037299
2014-11-26 12:56 Ben Boeckel Note Added: 0037300
2014-11-26 13:57 Brad King Note Added: 0037301
2014-12-01 09:14 Brad King Note Added: 0037323
2014-12-01 11:23 Brad King Status assigned => resolved
2014-12-01 11:23 Brad King Resolution open => fixed
2014-12-01 11:23 Brad King Fixed in Version => CMake 3.1
2015-05-04 09:05 Robert Maynard Note Added: 0038683
2015-05-04 09:05 Robert Maynard Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team