<div class="gmail_quote">On Fri, Jun 25, 2010 at 3:00 PM, Ed Loper <span dir="ltr"><<a href="mailto:eloper@bbn.com">eloper@bbn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 6/10/2010 2:34 PM, Ed Loper wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I have a CMake project that works fine with CMake 2.6, but when I build<br>
Visual Studio output with CMake 2.8, it doesn't seem to get the target<br></div>
library linking information quite right. [...]<br>
</blockquote>
<br>
I managed to track down the cause of this problem. It can be reproduced with the following minimal CMakeLists.txt file:<br>
<br>
ADD_LIBRARY (Foo STATIC foo.c)<br>
ADD_EXECUTABLE (Bar bar.c)<br>
TARGET_LINK_LIBRARIES(Bar Foo)<br>
INCLUDE_EXTERNAL_MSPROJECT(Foo ${CMAKE_BINARY_DIR}/Foo/Foo.vcproj)<br>
<br>
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.<br>
<br>
(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.)<br>
<br>
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.<div>
<div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>I agree wholeheartedly. Thanks for the easy-to-repro case. Would you mind logging a bug in the bug tracker for this?</div><div><br></div><div>Name collisions between any two CMake targets should definitely not be allowed (i.e. -- be a configure error) within a single CMake binary tree...</div>
<div><br></div><div><br></div><div>David</div><div><br></div></div>