Целевые зависимости по сравнению с бинарными ссылками с библиотеками
Я не понимаю разницы между этими функциями Xcode.
Я строю и приложение, но функциональность приложения абстрагируется в библиотеки (поэтому их можно разделить отдельно как "SDK" ).
Итак, у меня есть рабочее пространство библиотечных проектов и проект приложения. Я могу добавить проекты библиотеки в проект приложения, выполнив "link binary with libraries". Это дает мне список проектов библиотеки .a
в текущей рабочей области, к которой я могу подключиться.
Я также могу добавить фреймворки здесь.
В бит "целевых зависимостей" все, что я могу добавить, это другие цели в текущем проекте.
То, что я действительно хочу сделать, - это то, что я хочу, чтобы мой проект приложения собирал все другие проекты библиотеки, когда я его создавал. Я также хочу сделать многословным, какие библиотеки используют приложение (и другие библиотеки) .
Так кто-нибудь, пожалуйста, объясните разницу, и будет ли то, что я делаю, это правильный способ сделать это?
Большое спасибо!
Ответы
Ответ 1
Здесь говорится здесь...
- Перетащите ваш продукт фреймворка (расположенный в папке "Продукты" ) в существующую фазу сборки бинарных ссылок с помощью библиотек. цель. Это заставляет приложение ссылаться на вашу инфраструктуру.
А...
- На вкладке "Общие" окна инспектора добавьте фреймворк в качестве зависимости для приложения. Добавление этой зависимости приводит к тому, что Xcode создайте целевую инфраструктуру перед созданием целевого приложения.
Зависимость сборки, которую вы устанавливаете в целевом приложении, вызывает структуру, которая должна быть построена перед приложением. Это важно потому что он гарантирует, что встроенная версия вашей структуры будет доступный для связи и встраивания в приложение. Из-за эта зависимость, вы можете установить активную цель вашего проекта Xcode к вашему заявлению и оставить его там.
Так кажется, что вы должны использовать оба. Кажется избыточным, потому что, если вы связываетесь с каркасом, то его зависимость. Полагаю, вам может понадобиться только ссылка на библиотеку, а не сборка в первую очередь. Хотя XCode, похоже, создает связанные библиотеки, даже если они не добавляются в раздел зависимости. Возможно, это результат параметра "Найти неявные зависимости" в настройках построения схемы.
Ответ 2
Я делаю что-то подобное и явно устанавливаю "путь поиска заголовка" и "путь поиска библиотеки" в конечной исполняемой цели. Однако все это зависело от того, где были сгенерированы объекты. Первоначально я установил это в исходное дерево (на самом деле это sibling-каталог под названием build
), однако после изменения местоположения каталога Xcode DerivedData
и указания его на сборку в этот каталог проекты больше не строились.
Окончательным решением было просто удалить явную настройку "пути поиска заголовка/библиотеки" и правильно установить целевые зависимости. Это привело к созданию проекта для отладки и архивирования без проблем.