MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013685CMakeCMakepublic2012-11-15 10:362016-01-04 11:52
ReporterMike Smith 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformVisual Studio 2010OSWindowsOS Version7
Product VersionCMake 2.8.10.1 
Target VersionCMake 3.4Fixed in VersionCMake 3.4 
Summary0013685: No way to control object file suffix for Object Libraries
DescriptionThe suffix used for binary files when they are part of an Object Library seem to always be .obj on Windows. I was hoping that the setting for CMAKE_CXX_OUTPUT_EXTENSION and CMAKE_C_OUTPUT_EXTENSION would be used. When I try setting these values to .o it has no effect (see attached files). Alternatively it would be very useful to have some mechanism to set the suffix for these files.
Steps To ReproduceRun the attached files through cmake on Windows
Open the project in Visual Studio
The Object Library has the file main.obj - I want this to be main.o
Additional Information
TagsNo tags attached.
Relationships
Attached Fileszip cmake-test.zip (538) 2012-11-15 10:36
https://public.kitware.com/Bug/file/4564/cmake-test.zip
patch 0001-Fixed-issue-0013685.patch (1,848) 2015-08-18 10:20
https://public.kitware.com/Bug/file/5510/0001-Fixed-issue-0013685.patch
patch 0001-Fixed-coding-style.patch (1,858) 2015-08-18 11:05
https://public.kitware.com/Bug/file/5511/0001-Fixed-coding-style.patch
patch 0001-Fixed-issue-0013685-using-GetLanguageOutputExtension.patch (1,443) 2015-08-18 11:18
https://public.kitware.com/Bug/file/5512/0001-Fixed-issue-0013685-using-GetLanguageOutputExtension.patch
Issue History
Date ModifiedUsernameFieldChange
2012-11-15 10:36Mike SmithNew Issue
2012-11-15 10:36Mike SmithFile Added: cmake-test.zip
2012-11-15 10:56Brad KingNote Added: 0031561
2012-11-15 11:14Mike SmithNote Added: 0031562
2012-11-15 11:27Brad KingNote Added: 0031563
2012-11-15 11:27Brad KingSeverityminor => feature
2012-11-15 11:27Brad KingStatusnew => backlog
2012-11-19 10:03Mike SmithNote Added: 0031608
2012-11-19 10:09Brad KingNote Added: 0031609
2015-08-18 10:20Bastien SchattFile Added: 0001-Fixed-issue-0013685.patch
2015-08-18 10:26Bastien SchattNote Added: 0039297
2015-08-18 10:42Brad KingNote Added: 0039298
2015-08-18 11:05Bastien SchattFile Added: 0001-Fixed-coding-style.patch
2015-08-18 11:18Bastien SchattFile Added: 0001-Fixed-issue-0013685-using-GetLanguageOutputExtension.patch
2015-08-18 11:20Bastien SchattNote Added: 0039299
2015-08-20 09:41Brad KingNote Added: 0039304
2015-08-20 09:41Brad KingStatusbacklog => resolved
2015-08-20 09:41Brad KingResolutionopen => fixed
2015-08-20 09:41Brad KingFixed in Version => CMake 3.4
2015-08-20 09:41Brad KingTarget Version => CMake 3.4
2016-01-04 11:52Robert MaynardNote Added: 0040117
2016-01-04 11:52Robert MaynardStatusresolved => closed

Notes
(0031561)
Brad King   
2012-11-15 10:56   
For the IDE generator CMake never generates any project file settings to change the .obj extension, for an OBJECT library or otherwise. This would be a new general-purpose feature, no? Since the VS IDE does not present any interface treating object files as first-class entities (it calls them "intermediate" files), what difference does the extension make?

Note that OBJECT libraries have no packaged library file. The ".lib" built by the IDE is hidden away and not used and only exists because we can't stop the IDE from running its librarian. When the OBJECT library is referenced in another target then CMake directly adds the .obj files to the link line for that target. They will be included among the .obj files compiled from sources in that other (real) target when linking. Those will also always have ".obj" as their extension.

The CMAKE_C_OUTPUT_EXTENSION variables are only used for non-IDE generators IIRC.
(0031562)
Mike Smith   
2012-11-15 11:14   
The problem I am facing has come about because I am building using Visual Studio but with a non-Win32 cl.exe which creates .o object files, not .obj files. In the project files created by cmake it is .obj files listed but these can never be found during the build as the compiler produces .o files. The only work-around I have found so far is to manually hack the .vcxproj files after cmake has created them which isn't ideal.

> This would be a new general-purpose feature, no?
Yes, I guess so.
(0031563)
Brad King   
2012-11-15 11:27   
I see. Each generator has a "ComputeTargetObjects" method to predict the location of the object files. For VS it is here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudioGenerator.cxx;hb=v2.8.10.1#l113 [^]

Currently it hard-codes ".obj". Try teaching it to lookup the value through gt->Makefile->GetDefinition(...).
(0031608)
Mike Smith   
2012-11-19 10:03   
I tried your suggestion with CMAKE_C_OUTPUT_EXTENSION but it still always comes out as ".obj" (or NULL). Where would this value get set? I can take a look to see what is happening there.
(0031609)
Brad King   
2012-11-19 10:09   
The value of CMAKE_C_OUTPUT_EXTENSION is initialized here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeCInformation.cmake;hb=v2.8.10.1#l21 [^]

but may be overridden by platform/compiler-specific modules loaded later in that file.
(0039297)
Bastien Schatt   
2015-08-18 10:26   
I attached a patch based on your suggestion (i.e. using the value of CMAKE_C_OUTPUT_EXTENSION).
(0039298)
Brad King   
2015-08-18 10:42   
Thanks. The proper extension can be obtained from cmGlobalGenerator::GetLanguageOutputExtension, just like cmLocalGenerator::GetObjectFileNameWithoutTarget does. Please revise to use that instead. Otherwise this will only work when C is enabled.
(0039299)
Bastien Schatt   
2015-08-18 11:20   
Thank you for the review. I didn't know about GetLanguageOutputExtension.

I attached a new patch (0001-Fixed-issue-0013685-using-GetLanguageOutputExtension.patch).
(0039304)
Brad King   
2015-08-20 09:41   
Re 0013685:0039299: Thanks, applied:

 cmLocalVisualStudioGenerator: Use computed .obj extension
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3e94f94b [^]
(0040117)
Robert Maynard   
2016-01-04 11:52   
Closing resolved issues that have not been updated in more than 4 months.