MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0009214CMakeCMakepublic2009-06-28 01:182010-12-14 15:54
ReporterGreg Sharp 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionduplicate 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in VersionCMake 2.8.4 
Summary0009214: -D option can't use value with equals sign
DescriptionI can't seem to use the -D option to create a value with an equal sign. This is with cmake 2.6.4 on linux. For example:

$ cat myscript.cmake
MESSAGE("FOO is ${FOO}")
$ cmake -DFOO=bar -P myscript.cmake
FOO is bar
$ cmake -DFOO=bar=baz -P myscript.cmake
FOO is
$ cmake -DFOO="bar=baz" -P myscript.cmake
FOO is
$ cmake -DFOO=bar\=baz -P myscript.cmake
FOO is
$ cmake -DFOO="bar\=baz" -P myscript.cmake
FOO is
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0010356closed Ben Boeckel Problem specifying arguments on the command line containing '=' 
Attached Filespatch cmCacheManager.cxx.patch (720) 2009-10-12 10:58
https://public.kitware.com/Bug/file/2550/cmCacheManager.cxx.patch
Issue History
Date ModifiedUsernameFieldChange
2009-06-28 01:18Greg SharpNew Issue
2009-10-12 10:58Tim WhiteFile Added: cmCacheManager.cxx.patch
2009-10-12 11:08Tim WhiteNote Added: 0018058
2009-10-12 11:09Tim WhiteNote Edited: 0018058
2010-12-14 15:50David ColeRelationship addedduplicate of 0010356
2010-12-14 15:51David ColeAssigned To => David Cole
2010-12-14 15:51David ColeStatusnew => assigned
2010-12-14 15:51David ColeNote Added: 0023970
2010-12-14 15:51David ColeStatusassigned => closed
2010-12-14 15:52David ColeResolutionopen => duplicate
2010-12-14 15:52David ColeFixed in Version => CMake 2.8.4

Notes
(0018058)
Tim White   
2009-10-12 11:08   
(edited on: 2009-10-12 11:09)
This is a bug in a regex in ParseEntry() in cmCacheManager.cxx. I've uploaded a (1-character!) patch to fix it. :)

There are 2 ParseEntry() routines, and only the version that does not extract a variable type has this bug. So, a workaround is:

$ cmake -DFOO:STRING=bar=baz

BTW I would have ticked "major" for severity -- compilers like xlc expect options of the form "-option=value" and it took me a while to figure out what was going wrong. Also, it wouldn't hurt to reduce code duplication between the two ParseEntry() variants, but that would mean looking at all call sites and I don't have that much energy... :)
(0023970)
David Cole   
2010-12-14 15:51   
This should be fixed when the duplicate bug is fixed...