Target_link_libraries и add_dependencies

Ответ 1

В текущих выпусках CMake:

После некоторой проверки ошибок add_dependencies приводит к вызову Target->AddUtility(). x добавляется в список утилиты для my-lib.

target_link_libraries не приводит к вызову AddUtility, но он добавляет аргументы в свойство LINK_LIBRARIES target.

Позже, как содержимое свойства LINK_LIBRARIES target, так и список утилит используются для вычисления зависимостей цели в cmComputeTargetDepends.

Список утилит в целевом объекте не может быть запрошен во время настройки и используется только при генерации времени, поэтому использование add_dependencies с аргументами, которые уже добавлены с помощью target_link_libraries, является избыточным.

Ответ 2

Я не знаю, что вас особенно интересует...

С концептуальной точки зрения - я думаю, что вы правы. Это пустая трата байтов.

С точки зрения документации CMake - вы должны предпочесть make так, чтобы гарантировать правильный порядок сборки.

Согласно документации target_link_libraries, концепции add_dependencies были идеологически разделены. Такая идея разделения зависимостей и параметров компоновщика также сохраняется в формате Makefile в инструменте make GNU make.

target_link_libraries

..Укажите библиотеки или флаги, которые будут использоваться при связывании заданной цели.

add_dependencies

... Заставьте <target> верхнего уровня зависеть от других целей верхнего уровня, чтобы убедиться, что они строятся раньше, чем <target>...

В современном CMake из 3. * вы можете опустить add_dependencies, если будете выполнять связывание с псевдонимом цели:

add_library(fooLib 1.cpp 2.cpp)
add_library(my::fooLib ALIAS fooLib)
...
target_link_libraries(fooBin my::fooLib)

Ответ 3

Он используется в случаях, когда цели верхнего уровня зависят друг от друга. То есть, если x - это то, что вы добавляете в свой проект (на верхнем уровне) с помощью

add_library( x x.c y.c z.c )

вы скажете CMake об этом. И вы делаете это с помощью add_dependencies.