View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015959CMakeCMakepublic2016-02-08 02:562016-06-10 14:21
ReporterJon Kristensen 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformIntelOSWindowsOS Version7
Product VersionCMake 3.4.3 
Target VersionCMake 3.5Fixed in VersionCMake 3.5 
Summary0015959: Using CMake-Gui to run generate for Windows followed by generate for Unix generates incorrect Unix makefiles
DescriptionRunning a generator that uses the Windows Shell, and then running a generator that uses the Unix shell without exiting Cmake-gui first, causes the Unix makefiles to have the wrong shell command (SHELL = cmd.exe) and Windows path names (with ‘\’s instead of ‘/’s).


Steps To Reproduce1. Start cmake-gui
2. Select a project that uses the Visual Studio 2015 generator and run generate
3. Select a project that uses the CDT4 – Unix makefiles and run generate
Additional InformationAssumed cause (based on cmake-3.4.3 source distribution) :

The selection of shell seems to be based on the variable cmState::windowsShell
This variable is set to false in the cmState constructor,
and is set to true (through a call to member SetWindowsShell(true) from all generators that use a Windows shell.
But I could find no code that resets it if a non-Windows-Shell generator is run at a later time
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0040444)
Brad King (manager)
2016-02-08 09:15

 Thanks. Please try setting it in cmState::Reset.
(0040478)
Jon Kristensen (reporter)
2016-02-12 09:41

 Looks ok to me.
Tried to test, but I seem to be unable to build cmake-gui as I do not have Qt installed.
(0040479)
Brad King (manager)
2016-02-12 10:25

 This should fix it:

 cmake-gui: Fix cmState initialization when changing generators
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da490e11 [^]

You can test it with a nightly binary from here:

 https://cmake.org/files/dev/?C=M;O=D [^]

Version cmake-3.5.20160212 should show up tonight with this fix.
(0040489)
Jon Kristensen (reporter)
2016-02-15 03:34

 I have verified that cmake-3.5.20160212 fixed my problem.
Thanks.
(0040494)
Brad King (manager)
2016-02-16 09:50

 Great, thanks for testing. I've queued this fix for merge to 'release' for inclusion in 3.5.
(0041251)
Kitware Robot (administrator)
2016-06-10 14:21

 This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2016-02-08 02:56 Jon Kristensen New Issue
2016-02-08 09:15 Brad King Note Added: 0040444
2016-02-12 09:41 Jon Kristensen Note Added: 0040478
2016-02-12 10:25 Brad King Note Added: 0040479
2016-02-15 03:34 Jon Kristensen Note Added: 0040489
2016-02-16 09:50 Brad King Note Added: 0040494
2016-02-16 09:50 Brad King Assigned To => Brad King
2016-02-16 09:50 Brad King Status new => resolved
2016-02-16 09:50 Brad King Resolution open => fixed
2016-02-16 09:50 Brad King Fixed in Version => CMake 3.5
2016-02-16 09:50 Brad King Target Version => CMake 3.5
2016-06-10 14:21 Kitware Robot Note Added: 0041251
2016-06-10 14:21 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team