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
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.
target_link_libraries
..Specify libraries or flags to use when linking a given target..
add_dependencies
...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)
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.