Целевые зависимости по сравнению с бинарными ссылками с библиотеками

Я не понимаю разницы между этими функциями Xcode.

Я строю и приложение, но функциональность приложения абстрагируется в библиотеки (поэтому их можно разделить отдельно как "SDK" ).

Итак, у меня есть рабочее пространство библиотечных проектов и проект приложения. Я могу добавить проекты библиотеки в проект приложения, выполнив "link binary with libraries". Это дает мне список проектов библиотеки .a в текущей рабочей области, к которой я могу подключиться.

Я также могу добавить фреймворки здесь.

В бит "целевых зависимостей" все, что я могу добавить, это другие цели в текущем проекте.

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

Так кто-нибудь, пожалуйста, объясните разницу, и будет ли то, что я делаю, это правильный способ сделать это?

Большое спасибо!

Ответ 1

Здесь говорится здесь...

  1. Перетащите ваш продукт фреймворка (расположенный в папке "Продукты" ) в существующую фазу сборки бинарных ссылок с помощью библиотек. цель. Это заставляет приложение ссылаться на вашу инфраструктуру.

А...

  1. На вкладке "Общие" окна инспектора добавьте фреймворк в качестве зависимости для приложения. Добавление этой зависимости приводит к тому, что Xcode создайте целевую инфраструктуру перед созданием целевого приложения.

Зависимость сборки, которую вы устанавливаете в целевом приложении, вызывает структуру, которая должна быть построена перед приложением. Это важно потому что он гарантирует, что встроенная версия вашей структуры будет доступный для связи и встраивания в приложение. Из-за эта зависимость, вы можете установить активную цель вашего проекта Xcode к вашему заявлению и оставить его там.

Так кажется, что вы должны использовать оба. Кажется избыточным, потому что, если вы связываетесь с каркасом, то его зависимость. Полагаю, вам может понадобиться только ссылка на библиотеку, а не сборка в первую очередь. Хотя XCode, похоже, создает связанные библиотеки, даже если они не добавляются в раздел зависимости. Возможно, это результат параметра "Найти неявные зависимости" в настройках построения схемы.

Ответ 2

Я делаю что-то подобное и явно устанавливаю "путь поиска заголовка" и "путь поиска библиотеки" в конечной исполняемой цели. Однако все это зависело от того, где были сгенерированы объекты. Первоначально я установил это в исходное дерево (на самом деле это sibling-каталог под названием build), однако после изменения местоположения каталога Xcode DerivedData и указания его на сборку в этот каталог проекты больше не строились.

Окончательным решением было просто удалить явную настройку "пути поиска заголовка/библиотеки" и правильно установить целевые зависимости. Это привело к созданию проекта для отладки и архивирования без проблем.