MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013831CMakeCMakepublic2013-01-03 17:332013-06-03 09:05
ReporterAmine Khaldi 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 2.8.10.2 
Target VersionCMake 2.8.11Fixed in VersionCMake 2.8.11 
Summary0013831: VS 2012 generator doesn't always respect the EXTERNAL_OBJECT propery
DescriptionWe (ReactOS) tried to work around the lack of support for preprocessed asm file in the VS generators, by creating a custom command where we preprocess using cl and then pass to ml to generate objects. We then add these objects back as source files for the target in question, marking them as EXTERNAL_OBJECT. This works perfectly for the normal makefiles, the objects get used in the linker. With the VS 2010 generator we get these objects as "not part of the build" while they should in fact be Objects.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0013047closed Brad King Visual Studio 2010 Generator and "PROPERTIES GENERATED 1" adds .obj as "not part of this build" to projects 
related to 0011891closed Bill Hoffman Visual Studio 2010 Generator adds .obj as "not part of this build" to projects 
Attached Filespatch c7550d5e+0001-VS11-Simplify-external-object-file-handling-13831.patch (3,256) 2013-01-07 11:51
https://public.kitware.com/Bug/file/4612/*
Issue History
Date ModifiedUsernameFieldChange
2013-01-03 17:33Amine KhaldiNew Issue
2013-01-04 08:24Brad KingNote Added: 0031974
2013-01-04 08:32Amine KhaldiNote Added: 0031976
2013-01-04 08:47Brad KingRelationship addedrelated to 0013047
2013-01-04 08:50Amine KhaldiNote Added: 0031979
2013-01-04 08:54Brad KingNote Added: 0031980
2013-01-04 08:54Brad KingRelationship addedrelated to 0011891
2013-01-04 08:57Brad KingNote Added: 0031981
2013-01-06 09:32Amine KhaldiNote Added: 0031988
2013-01-07 11:50Brad KingSummaryVS 2010 generator doesn't respect the EXTERNAL_OBJECT propery => VS 2012 generator doesn't always respect the EXTERNAL_OBJECT propery
2013-01-07 11:51Brad KingFile Added: c7550d5e+0001-VS11-Simplify-external-object-file-handling-13831.patch
2013-01-07 11:52Brad KingNote Added: 0031995
2013-01-07 12:23Amine KhaldiNote Added: 0031997
2013-01-07 13:56Brad KingNote Added: 0031998
2013-01-07 13:56Brad KingAssigned To => Brad King
2013-01-07 13:56Brad KingStatusnew => resolved
2013-01-07 13:56Brad KingResolutionopen => fixed
2013-01-07 13:56Brad KingFixed in Version => CMake 2.8.11
2013-01-07 13:56Brad KingTarget Version => CMake 2.8.11
2013-06-03 09:05Robert MaynardNote Added: 0033179
2013-06-03 09:05Robert MaynardStatusresolved => closed

Notes
(0031974)
Brad King   
2013-01-04 08:24   
CMake has a test for external objects:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/ExternalOBJ/CMakeLists.txt;hb=v2.8.10.2 [^]

It passes with VS 10. Please provide a sample test case that fails.
(0031976)
Amine Khaldi   
2013-01-04 08:32   
We use it in a macro that basically does:
macro(add_asm_files _target)
    get_includes_and_defines_from_directory()
    foreach(_source_file ${ARGN})
        get_source_file_defines()
        add_custom_command(pass the source file to cl for preprocessing, then to ml for compiling an object file)
        set_source_files_properties(${_object_file} PROPERTIES EXTERNAL_OBJECT 1)
        list(APPEND ${_target} ${_object_file})
    endforeach()
endmacro()

and we add that _target to the source files in add_library() for example. In VS you get "None" for these objects.

Here's a patch that "fixed" the issue for me: http://pastebin.com/m8Q9S6n5 [^]
(0031979)
Amine Khaldi   
2013-01-04 08:50   
Side question, what's the rationale behind not including external objects into object libraries ? I tried to make an objects lib out of these generated object asm files, but I got an error that explained how object libraries are only used for source files and headers.
(0031980)
Brad King   
2013-01-04 08:54   
All files in the ExternalObjects list are EXTERNAL_OBJECT. That's how they get put in the list, so the "if" condition in your patch is not necessary.

The current behavior was established by these changes:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a6ff950 [^]
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b291d9e7 [^]

I'll have to look again at why "None" is ever correct.
(0031981)
Brad King   
2013-01-04 08:57   
Re 0013831:0031979: Simplicity. We made all but the basic use case an error to make the initial implementation easier while preserving room for future expansion.
(0031988)
Amine Khaldi   
2013-01-06 09:32   
Brad, I made a typo when reporting this bug. It happens with VS *11* generator, with the 10 generator it works exactly like you mentioned. Is there something different in the CMake codebase, between 10 and 11, w.r.t. handling dependencies ? For example I see with 10 in pseh.dir\Debug\lib.command.1.tlog those external objects listed, but with 11 they're not.
(0031995)
Brad King   
2013-01-07 11:52   
The ExternalOBJ test passes on VS 11 too, but it looks like VS 11 added a feature that affects this behavior and can make things simpler. Please try "c7550d5e+0001-VS11-Simplify-external-object-file-handling-13831.patch".
(0031997)
Amine Khaldi   
2013-01-07 12:23   
Confirmed.. That fixes the issue for VS11
(0031998)
Brad King   
2013-01-07 13:56   
Thanks for testing. Patch applied:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b684b395 [^]
(0033179)
Robert Maynard   
2013-06-03 09:05   
Closing resolved issues that have not been updated in more than 4 months.