[CMake] Question about transitive dependencies

[David Cole]

target_link_libraries takes target names as its arguments as well as full
paths to libraries. Just use CMake target names in target_link_libraries
calls and do NOT use add_dependencies for libraries.
add_dependencies is very useful for custom targets and custom commands to
guarantee build order. I have never heard of anybody else using it to add
library-to-library or executable-to-library dependencies.

target_link_libraries is really the way to go.


On Thu, Dec 4, 2008 at 5:12 PM, Robert Dailey <rcdailey at gmail.com> wrote:

> On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf <
> a.neundorf-work at gmx.net> wrote:
>
>> But, if you do in cmake:
>> target_link_libraries(staticLibB staticLibA)
>> this will not really link (as it would for a shared lib), but it will
>> nevertheless keep track of the dependencies.
>> So when liking
>> target_link_libraries(myApp staticLibB)
>> cmake knows that it has to add staticLibA to the linker command.
>
>
> But that's one of the things that really bothers me. This is that
> redundancy I was talking about earlier. If I do:
>
> add_dependencies( C B )
> target_link_libraries( C staticLibB )
>
> It's a bit pointless. For example, CMake should be smart enough to know
> that by adding a dependency to B, it should look at the library that it is
> outputting (In this case, staticLibB.lib) and add that to an implicit call
> to target_link_libraries(). I only want to use target_link_libraries() to
> link against external third party libraries that aren't explicitly
> represented as a project in my CMake build process.
>
> If I decide to change the output name for the static library B outputs, I'm
> forced to then revisit all of the target_link_libraries() calls and rename
> staticLibB. This is a management issue (amongst other things).
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20081204/aae6365e/attachment.htm>