target_link_libraries and add_dependencies

前端 未结 2 1253
不思量自难忘°
不思量自难忘° 2021-02-11 18:30

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

相关标签:
2条回答
  • 2021-02-11 19:24

    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)
    
    0 讨论(0)
  • 2021-02-11 19:28

    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.

    0 讨论(0)
提交回复
热议问题