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 <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf < > [EMAIL PROTECTED]> 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@cmake.org > http://www.cmake.org/mailman/listinfo/cmake >
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
