MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007235CMakeCMakepublic2008-06-24 08:562016-06-10 14:30
ReporterAdam Strzelecki 
Assigned ToBill Hoffman 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0007235: RC generation broken for MinGW, causes infinite loop for CL (Microsoft compiler) (w/patch)
DescriptionMinGW does have only Microsoft's RC recipe for generating resource files using "rc" command, while MinGW uses its own "windres".

Moreover latest enable_language change causes infinite loop in Windows-cl.cmake that enables RC language:
               [103] /opt/local/share/cmake-2.6/Modules/Platform/Windows-cl.cmake
                [102] /opt/local/share/cmake-2.6/Modules/CMakeSystemSpecificInformation.cmake
                [101] /opt/local/share/cmake-2.6/Modules/Platform/Windows-cl.cmake
                [100] /opt/local/share/cmake-2.6/Modules/CMakeSystemSpecificInformation.cmake
                [99] /opt/local/share/cmake-2.6/Modules/Platform/Windows-cl.cmake
                [98] /opt/local/share/cmake-2.6/Modules/CMakeSystemSpecificInformation.cmake
                [97] /opt/local/share/cmake-2.6/Modules/Platform/Windows-cl.cmake
                [96] /opt/local/share/cmake-2.6/Modules/CMakeSystemSpecificInformation.cmake
 
Removing ENABLE_LANGUAGE(RC) from Windows-cl.cmake solves the problem.

Adding COMPILE_RC_OBJECT definition to Windows-gcc makes it use "windres" properly.

I've added also "windres" to CMakeDetermineRCCompiler.cmake, however it has different command line, that is specified next to compiler (Windows-gcc.cmake or cl.cmake), so it may be a problem when we have mixed environment and "rc" will be taken from Microsoft env,(1st in the list) while gcc from MingW will be requested. I'm not sure how to sort it out.

So this patch needs review. Anyway it is not possible to build RC files with MinGW with 2.6.0 so I believe it should fixed before 2.6.1.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Filespatch CMake_broken_RC_generation.patch (5,874) 2008-06-24 08:56
https://public.kitware.com/Bug/file/1556/CMake_broken_RC_generation.patch
Issue History
Date ModifiedUsernameFieldChange
2008-06-24 08:56Adam StrzeleckiNew Issue
2008-06-24 08:56Adam StrzeleckiFile Added: CMake_broken_RC_generation.patch
2008-06-24 15:55Bill HoffmanNote Added: 0012505
2008-06-24 17:03Adam StrzeleckiNote Added: 0012509
2008-08-21 09:01Bill HoffmanStatusnew => assigned
2008-08-21 09:01Bill HoffmanAssigned To => Bill Hoffman
2008-08-26 13:18Michał FitaNote Added: 0013189
2014-10-21 20:09Timothy GuNote Added: 0037060
2016-06-10 14:27Kitware RobotNote Added: 0041433
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0012505)
Bill Hoffman   
2008-06-24 15:55   
I have removed the optional for RC, that caused the infinite stuff. Turns out for embeded resources stuff, we use the rc compiler as well, so we have to have it. I will look at the patch, we want to make sure that gcc uses windres and cl uses rc right?
(0012509)
Adam Strzelecki   
2008-06-24 17:03   
> we want to make sure that gcc uses windres and cl uses rc right?

Exactly. Moreover gcc's windres has different than cl's rc syntax:

<windres> --input-format rc --output-format coff -I<includes> -i<input> -o<output>
(0013189)
Michał Fita   
2008-08-26 13:18   
What is additional important thing, it could not accept path with spaces as argv[0] (simialar to g++). I found CMakeSetup sets my CMAKE_CXX_COMPILER to C:\Progra~1\MinGW\bin\g++.exe. Similar for mingw32-make.exe.

If this is intentional, should be intentional same way for windres.exe.

I hope it would be released soon corrected. I need this very much.
(0037060)
Timothy Gu   
2014-10-21 20:09   
This bug has been partially addressed by http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b2f308c8f9b4ded77f0693b39c0288e3bbb00977 [^] , but the solution is not complete, as the scripts must be manually included in CMakeLists.txt.

I have sent a patch fixing this issue: http://public.kitware.com/pipermail/cmake-developers/2014-October/011728.html [^]
(0041433)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

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.