Is there any use case in which
target_link_libraries(my-lib x y z) add_dependencies(my-lib x) # this is not just a waste of bytes? If so, can someone explain what it would be?
3 Answers
In current CMake releases:
After some error checking add_dependencies results in a call to Target->AddUtility(). x is added to the list of utilities for my-lib.
target_link_libraries does not result in a call to AddUtility, but it does add the arguments to the LINK_LIBRARIES target property.
Later, both the content of the LINK_LIBRARIES target property and the list of utilities are used to compute the dependencies of the target in cmComputeTargetDepends.
The list of utilities in a target can not be queried at configure time, and is only used at generate time, so the use of add_dependencies with arguments which are libraries already added with target_link_libraries is redundant.
I don't know what you're particularly interested in...
From a conceptual point of view -- I think you're right. It is a waste of bytes.
From a CMake documentation point of view -- You should prefer make so to guarantee the correct build order.
According to the documentation target_link_libraries, add_dependencies concepts was ideologically split. Such an idea of split dependencies, and linker options is also persisted in the Makefile format in the GNU make tool.
..Specify libraries or flags to use when linking a given target..
...Make a top-level <target> depend on other top-level targets to ensure that they build before <target> does...
In modern CMake from 3.* you can omit add_dependencies if you will perform linking with an aliased target:
add_library(fooLib 1.cpp 2.cpp) add_library(my::fooLib ALIAS fooLib) ... target_link_libraries(fooBin my::fooLib) It's used in cases where top-level targets depend on each other. That is, if x is a something that you add to your project (at top-level) with
add_library( x x.c y.c z.c ) you shall tell CMake about it. And you do that with add_dependencies.
2
