Notes |
|
(0025965)
|
Bill Hoffman
|
2011-03-30 09:45
|
|
|
|
(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. |
|