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

[David Cole]

On Fri, Jun 25, 2010 at 3:00 PM, Ed Loper <eloper at bbn.com> wrote:

> 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.
>
>
I agree wholeheartedly. Thanks for the easy-to-repro case. Would you mind
logging a bug in the bug tracker for this?

Name collisions between any two CMake targets should definitely not be
allowed (i.e. -- be a configure error) within a single CMake binary tree...


David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100625/2bdbb361/attachment.htm>