[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