Как вы получаете неявные зависимости для работы с рабочими пространствами в Xcode 4?

Question

Я хочу управлять проектами в рабочих пространствах, используя Xcode 4 с проектами Cocoa Touch Static Library, которые содержат общий код, на который я мог ссылаться из других проектов.В соответствии с видео WWDC 2010 и документацией по Xcode 4, есть функция «неявных зависимостей» для рабочих пространств в Xcode 4. Я пытался заставить это работать, и у меня не было большого успеха.

Пример рабочей области: DependenciesInXcode4.zip

Вы видите, что в самом простом примере проекта есть 2 статических проекта библиотеки, которые я назвал Library1 и Library2.Затем у меня есть отдельный класс в каждом проекте, на который я ссылаюсь из проекта iPhone под названием PrimaryApp.Я получаю поддержку Code Sense при добавлении оператора импорта, но сборка завершается неудачей.

Вы можете увидеть, как сборка завершается неудачно, поскольку она не может найти зависимости.

Для решения этих проблем я добавил вручную связанные проекты Library1 и Library2.

Мне также пришлось добавить путь к этим проектам какПути поиска в заголовке.

Теперь, когда я собираю обе библиотеки зависимостей, а затем запускаю PrimaryApp в симуляторе iPhone, он успешно создается и работает.Я обнаружил, что это не всегда гарантирует, что проекты зависимостей создаются при необходимости, и это явно ручной процесс.Это не то, что я считаю "неявными зависимостями", поскольку видео и документация XCode подразумевают, что это должно работать.Я искал более конкретные примеры, но пока мне не повезло.Даже здесь, в Stackoverflow, я пока не вижу удовлетворительного ответа.

• Как мне управлять зависимостями между проектами в рабочей области XCode?
• Что такоеправильный способ настройки рабочих пространств XCode 4 для построения зависимостей при необходимости?

Похоже, что разработчики прибегают к старым методам и не используют по-настоящему новые функции "неявных зависимостей".

Буду признателен за помощь в понимании того, как заставить «неявные зависимости» работать с рабочими пространствами в Xcode 4.

Вот мои вопросы:

• Как дела?неявные зависимости "должны работать в Xcode 4 с рабочими пространствами?
• Почему код в Libary1 и Library2 не может быть автоматически найден в PrimaryApp?
• Требуются ли дополнительные изменения для работы зависимостей в рабочей области?

Answer 1

Я только что провел лучшую часть двух дней, строя и перестраивая наш проект, борясь только с этой самой проблемой.Несмотря на то, что у меня теперь есть проект, который правильно строит и связывает И имеет работающий кодовый смысл, я не на 100% доволен одним из шагов, так как он кажется мне взломанным и, конечно, не соответствует моей концепции «Автоматических неявных зависимостей».,

FWIW вот шаги, которые я предпринял:

1. Создайте новое рабочее пространство в Xcode.
2. Добавьте новый проект в рабочую область для вашей статической библиотеки.Вы также можете добавить существующий проект, я обнаружил, что это тоже работает.
3. Проверьте, что библиотека собирается должным образом.
4. Добавьте новый проект в рабочую область для вашего основного проекта.Мне снова удалось добавить существующий, но, что важно, он не имел уже никаких настроек сборки, связанных с библиотекой.Если вы добавляете новый проект, достаточно просто добавить к нему существующие исходные файлы.Моя конкретная ситуация была осложнена очень большим ранее существующим SVN-хранилищем, которое я не хотел реструктурировать.
5. На этом этапе я собираюсь предположить, что ваш исходный код уже содержит импорт заголовков из статической библиотеки.
6. На этапах сборки для основного проекта разверните «двоичный файл связи с библиотеками»."и нажмите символ +.Выберите цель в своем проекте статической библиотеки.
7. Если вы хотите на этом этапе, вы можете построить основной проект, чтобы подтвердить, что он терпит неудачу, как показано на снимках экрана OP с ошибками «Нет такого файла ...» длязаголовок импортируется.
8. Теперь этот бит мне не очень нравится.В вашем основном проекте создайте новую группу и назовите ее «Зависимые заголовки» или как-то еще.Теперь в навигаторе проекта перетащите все используемые заголовки из статического проекта в эту новую группу.Во всплывающих опциях я просто оставил его как настройки по умолчанию.
9. Возможно, вам также понадобится связать ваш основной проект с любыми зависимыми библиотеками, используемыми вашей статической библиотекой.Например, моя статическая библиотека использует libxml2 и CFNetwork, и хотя мой основной проект не использует их напрямую, у меня были ошибки компиляции, если я не добавлял их на этапе сборки «связать двоичные файлы с библиотеками».
10. Вашосновной проект теперь (надеюсь) должен быть собран.

Мне действительно не нравятся шаги 8 и 9. Это действительно похоже на то, что XCode не делает то, что рекламируется.Однако, если и когда это будет исправлено, по крайней мере, эти шаги довольно легко отменить, чтобы они работали правильно.

Я думаю, что «неявные зависимости» должны работать без необходимости проходить мимо шага 6, возможно даже шага 5, ноэто может быть слишком автоматическим для вкуса многих людей.

Answer 2

Это действительно похоже на ошибку в обработке неявных зависимостей Xcode во время процесса сборки.

В рабочей области с двумя проектами я смог увидеть в проекте A классы в проекте B и успешно создать его, скопировав заголовочные файлы .h для классов проекта B в каталог проекта A. ПРИМЕЧАНИЕ. Я не добавил их в проект A в Xcode Я просто поместил их в каталог проекта A в Finder.

Это гораздо более простое решение, чем я видел в общих чертах, так как оно не требует никаких изменений в схемах рабочего пространства или в настройках сборки любого проекта. С помощью файлов .h в каталоге Project A Xcode смог автоматически найти и разрешить все неявные зависимости Project A от Project B.

К сожалению, вы не можете поместить файлы .h в их собственный подкаталог с именем "XcodeBugWorkaroundHeaderFiles". Они должны находиться в каталоге, из которого проект уже читает файлы .h. Кроме того, псевдонимы не будут работать, но символические ссылки будут работать, поэтому, используя SymLinks, вам не нужно беспокоиться об устаревших копиях.

Учитывая все вышесказанное, я не уверен, что наличие "скрытых" .h файлов, без которых сборка не удастся, является хорошей идеей. Пока ошибка не исправлена ​​в XCode, вероятно, лучше всего добавить их в проект, чтобы вы могли видеть их в XCode.

Answer 3

Чтобы решить проблемы с пробелами в путях поиска в заголовке пользователя, используйте

"${BUILT_PRODUCTS_DIR}"

Answer 4

Я получил это на работу, выполнив следующее. 1. Добавление библиотеки в качестве второго проекта в рабочую область. 2. Связать двоичные файлы с библиотеками> Добавить статическую библиотеку.

- ВАЖНАЯ ЧАСТЬ -

1. Добавьте следующее в «Пути поиска по заголовку» в настройках сборки

   $ {BUILT_PRODUCTS_DIR}

Это свяжет встроенные файлы заголовков с проектом. Больше нет ошибок сборки.

Answer 5

Вот все инструкции в одном документе Google Документы .

Answer 6

Другой вариант - просто включить корень каждого «подпроекта» в качестве пути рекурсивного заголовка. Например, если у вас есть AcmeLib, вы можете перейти к параметрам сборки основного проекта и добавить путь к AcmeLib к пути поиска заголовка пользователя с включенной рекурсивной опцией. Тогда заголовочные файлы вашей AcmeLib будут автоматически найдены.

Чтобы сохранить независимость пути между разработчиками, вы можете указать путь относительно переменной каталога источника, скажем, $ ACME_LIB, которую каждый разработчик может использовать на панели «Источники» параметров XCode.

Итак, чтобы использовать AcmeLib в новом проекте, просто перетащите его в проект, добавьте $ ACME_LIB в путь поиска заголовка, и все готово. Неявное связывание XCode должно соединять зависимости.