MantisBT - CMake
View Issue Details
0011896CMakeCMakepublic2011-02-24 15:262011-04-14 14:39
Shash Chatterjee 
Bill Hoffman 
normalmajoralways
closedfixed 
x86Microsoft WindowsXP Professional
CMake 2.8.4 
CMake 2.8.5CMake 2.8.5 
0011896: ".obj" or ".o" listed in ADD_LIBRARY does not get included in Visual Studio project, NMake build works
When adding an object-file (pre-compiled, available only in binary form from 3rd-party) to a library, the object file does not get included in the library when built under Visual Studio (tried Visual Studio 10/2010 and 8/2005).

When using NMake, for both VS-10 and VS-8, the object is included correctly.

If the project file for the library is updated manually, by selecting the project properties, and then adding the .o/.obj as an "Additional Dependencies" for the Librarian properties, then the build works.

An example source tree and 2 build directories are attached.
No tags attached.
has duplicate 0011891closed Bill Hoffman Visual Studio 2010 Generator adds .obj as "not part of this build" to projects 
tgz cmaketest.tgz (28,000) 2011-03-30 10:02
https://public.kitware.com/Bug/file/3789/cmaketest.tgz
zip cmake-42c5a04-ExternalObj.zip (2,539) 2011-04-01 10:02
https://public.kitware.com/Bug/file/3794/cmake-42c5a04-ExternalObj.zip
Issue History
2011-02-24 15:26Shash ChatterjeeNew Issue
2011-03-30 09:45Bill HoffmanNote Added: 0025965
2011-03-30 09:45Bill HoffmanNote Edited: 0025965bug_revision_view_page.php?bugnote_id=25965#r267
2011-03-30 10:02Shash ChatterjeeFile Added: cmaketest.tgz
2011-03-30 10:04Shash ChatterjeeNote Added: 0025967
2011-03-30 10:16Shash ChatterjeeNote Edited: 0025967bug_revision_view_page.php?bugnote_id=25967#r269
2011-03-30 10:28Shash ChatterjeeNote Added: 0025969
2011-03-30 10:36Bill HoffmanNote Added: 0025970
2011-03-31 18:06Bill HoffmanRelationship addedhas duplicate 0011891
2011-03-31 21:16Chris ScharverNote Added: 0026003
2011-04-01 10:02Chris ScharverFile Added: cmake-42c5a04-ExternalObj.zip
2011-04-01 10:51Bill HoffmanNote Added: 0026015
2011-04-01 10:52Bill HoffmanAssigned To => Bill Hoffman
2011-04-01 10:52Bill HoffmanStatusnew => assigned
2011-04-01 10:59Chris ScharverNote Added: 0026016
2011-04-04 17:28Bill HoffmanNote Added: 0026087
2011-04-04 17:28Bill HoffmanStatusassigned => closed
2011-04-04 17:28Bill HoffmanResolutionopen => fixed
2011-04-14 14:39David ColeFixed in Version => CMake 2.8.5
2011-04-14 14:39David ColeTarget Version => CMake 2.8.5

Notes
(0025965)
Bill Hoffman   
2011-03-30 09:45   
This should work. We even have a test that does this... ExternalOBJ

It has been passing for some time on the dashboard with all vs ide builds, including VS 10:

http://www.cdash.org/CDash/testDetails.php?test=89793743&build=926273 [^]

I don't see your attachment.

(0025967)
Shash Chatterjee   
2011-03-30 10:04   
(edited on: 2011-03-30 10:16)
Hi Bill,

The attachment likely failed because it was too big, or maybe 'cause I somehow goofed. Anyway, I have deleted the build-dir contents, remade a small compressed-tar and reattached it.

I wasn't using ExternalOBJ, will give it a try in the next day or two. Thanks for the info.

EDIT: Oh, I thought ExterrnalOBJ was a CMake command, you meant it as the name of a particular test. Please let me know if my attached example fails for you as well.

(0025969)
Shash Chatterjee   
2011-03-30 10:28   
I looked at the ExternalOBJ test. If I understand it correctly, what it does is not the problem mentioned in this bug-report. What ExternalOBJ does is to compile sources from an external directory, then does a ADD_EXECUTABLE with a source in the current directory and including objects in a different directory.

The problem in this bug-report has to do with including external objects in a library, then (eventually) linking to the library to build an executable.
(0025970)
Bill Hoffman   
2011-03-30 10:36   
The test use cmake to create a .o file. This a separate run of CMake. It then uses that .o or .obj as input to an executable. I guess the big difference is you are putting the .o in a library... Maybe that is the bug..
(0026003)
Chris Scharver   
2011-03-31 21:16   
I think the difference in behavior with the test is due to the fact that the test uses an object that is generated, thus the object is considered part of the compilation process somehow.

I managed to break the test by using ${EXTERNAL_OBJECT} instead of ${CUSTOM_OBJECT}. Perhaps the test should create two executables, each linking with a different object variable.
(0026015)
Bill Hoffman   
2011-04-01 10:51   
OK, I will update the test to create two executables one that uses the custom command generated obj and one that does not. Really strange why that works.... It could be used as a work around if folks are interested. All you need to do is copy the .o file with a custom command and it will work..
(0026016)
Chris Scharver   
2011-04-01 10:58   
I attached a modified version of the test. One executable works and one doesn't.
(0026087)
Bill Hoffman   
2011-04-04 17:28   
I fixed this and checked it into git next. The fix should be in the next release of CMake. Please try the next nightly cmake to verify that it works for you.