View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011896CMakeCMakepublic2011-02-24 15:262011-04-14 14:39
ReporterShash Chatterjee 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSMicrosoft WindowsOS VersionXP Professional
Product VersionCMake 2.8.4 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0011896: ".obj" or ".o" listed in ADD_LIBRARY does not get included in Visual Studio project, NMake build works
DescriptionWhen 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.

Steps To ReproduceAn example source tree and 2 build directories are attached.
TagsNo tags attached.
Attached Filestgz file icon cmaketest.tgz [^] (28,000 bytes) 2011-03-30 10:02
zip file icon cmake-42c5a04-ExternalObj.zip [^] (2,539 bytes) 2011-04-01 10:02

 Relationships
has duplicate 0011891closedBill Hoffman Visual Studio 2010 Generator adds .obj as "not part of this build" to projects 

  Notes
(0025965)
Bill Hoffman (manager)
2011-03-30 09:45
edited on: 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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
2011-04-01 10:58

 I attached a modified version of the test. One executable works and one doesn't.
(0026087)
Bill Hoffman (manager)
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.

 Issue History
Date Modified Username Field Change
2011-02-24 15:26 Shash Chatterjee New Issue
2011-03-30 09:45 Bill Hoffman Note Added: 0025965
2011-03-30 09:45 Bill Hoffman Note Edited: 0025965
2011-03-30 10:02 Shash Chatterjee File Added: cmaketest.tgz
2011-03-30 10:04 Shash Chatterjee Note Added: 0025967
2011-03-30 10:16 Shash Chatterjee Note Edited: 0025967
2011-03-30 10:28 Shash Chatterjee Note Added: 0025969
2011-03-30 10:36 Bill Hoffman Note Added: 0025970
2011-03-31 18:06 Bill Hoffman Relationship added has duplicate 0011891
2011-03-31 21:16 Chris Scharver Note Added: 0026003
2011-04-01 10:02 Chris Scharver File Added: cmake-42c5a04-ExternalObj.zip
2011-04-01 10:51 Bill Hoffman Note Added: 0026015
2011-04-01 10:52 Bill Hoffman Assigned To => Bill Hoffman
2011-04-01 10:52 Bill Hoffman Status new => assigned
2011-04-01 10:59 Chris Scharver Note Added: 0026016
2011-04-04 17:28 Bill Hoffman Note Added: 0026087
2011-04-04 17:28 Bill Hoffman Status assigned => closed
2011-04-04 17:28 Bill Hoffman Resolution open => fixed
2011-04-14 14:39 David Cole Fixed in Version => CMake 2.8.5
2011-04-14 14:39 David Cole Target Version => CMake 2.8.5

Copyright © 2000 - 2018 MantisBT Team