[CMake] Issue w/ relative library paths between targets in CMake 2.8 / Visual Studio 9 2008

Ed Loper eloper at bbn.com
Fri Jun 25 15:00:31 EDT 2010


On 6/10/2010 2:34 PM, Ed Loper wrote:
> I have a CMake project that works fine with CMake 2.6, but when I build
> Visual Studio output with CMake 2.8, it doesn't seem to get the target
> library linking information quite right. [...]

I managed to track down the cause of this problem.  It can be reproduced 
with the following minimal CMakeLists.txt file:

   ADD_LIBRARY (Foo STATIC foo.c)
   ADD_EXECUTABLE (Bar bar.c)
   TARGET_LINK_LIBRARIES(Bar Foo)
   INCLUDE_EXTERNAL_MSPROJECT(Foo ${CMAKE_BINARY_DIR}/Foo/Foo.vcproj)

The cause of the trouble is that the "Foo" target is getting re-used as 
both a library and an external-ms-project.  But with this ordering, we 
don't get any warnings or errors; just a broken vcproj file.  If the 
INCLUDE_EXTERNAL_MSPROJECT command is moved to before the 
TARGET_LINK_LIBRARY command, then we do get a (somewhat) helpful error 
message saying you can't link to UTILITY targets.

(In the case of the cmakefiles I was working with, the call to 
INCLUDE_EXTERNAL_MSPROJECT was in a totally different subdirectory from 
the ADD_LIBRARY declaration, and the name conflict was unintentional.)

It looks to me like cmake already complains if you try to overload names 
for some types of targets -- e.g., if I use both ADD_LIBRARY and 
ADD_EXECUTABLE with the same target name, I get an error.  I think it 
would be a good idea to extend this to all target types.  In particular, 
it would have been very helpful if I got an error when 
INCLUDE_EXTERNAL_MSPROJECT was called, since it's attempting to create a 
new target with the same name as an existing target.

Thanks,
-Edward



More information about the CMake mailing list