Как вы получаете неявные зависимости для работы с рабочими пространствами в Xcode 4?
Я хочу управлять проектами в рабочих пространствах с помощью 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 Simulator, он успешно собирается и запускается. Я обнаружил, что это не всегда гарантирует, что проекты зависимостей создаются при необходимости, и это явно ручной процесс. Это не то, что я считаю "неявными зависимостями", поскольку видео и документация XCode подразумевают, что это должно работать. Я искал более конкретные примеры, но пока мне не повезло. Даже здесь, на Stackru, я пока не вижу удовлетворительного ответа.
- Как я должен управлять зависимостями между проектами в рабочей области XCode?
- Как правильно настроить рабочие пространства XCode 4 для построения зависимостей при необходимости?
Похоже, что разработчики прибегают к старым методам и не используют по-настоящему новые функции "неявных зависимостей".
Я был бы признателен за помощь в понимании того, как заставить "неявные зависимости" работать с рабочими пространствами в Xcode 4.
Вот мои вопросы:
- Как "неявные зависимости" должны работать в Xcode 4 с рабочими пространствами?
- Почему код в Libary1 и Library2 не может быть автоматически найден в PrimaryApp?
- Требуются ли дополнительные изменения для работы зависимостей в рабочей области?
6 ответов
Я только что провел лучшую часть двух дней, строя и перестраивая наш проект, борясь только с этой самой проблемой. Несмотря на то, что у меня теперь есть проект, который правильно строит и связывает И имеет работающий кодовый смысл, я не на 100% доволен одним из шагов, так как он кажется мне взломанным и, конечно, не соответствует моей концепции "Автоматических неявных зависимостей".,
FWIW вот шаги, которые я предпринял:
- Создайте новое рабочее пространство в Xcode.
- Добавьте новый проект в рабочую область для вашей статической библиотеки. Вы также можете добавить существующий проект, я нашел, что это тоже работает.
- Проверьте, что библиотека строит, как ожидалось.
- Добавьте новый проект в рабочую область для вашего основного проекта. Мне снова удалось добавить существующий, но, что важно, он не имел уже никаких настроек сборки, связанных с библиотекой. Если вы добавляете новый проект, достаточно просто добавить к нему существующие исходные файлы. Моя конкретная ситуация была осложнена очень большим ранее существующим SVN-хранилищем, которое я не хотел реструктурировать.
- На этом этапе я собираюсь предположить, что ваш исходный код уже содержит импорт заголовков из статической библиотеки.
- На этапах сборки основного проекта разверните раздел "связать двоичный файл с библиотеками" и щелкните значок "+". Выберите цель из вашего проекта статической библиотеки.
- Если вы хотите на этом этапе, вы можете построить основной проект, чтобы убедиться, что он не работает, как показано на снимках экрана OP с ошибками "Нет такого файла..." для импорта заголовка.
- Это то, что мне не очень нравится. В вашем основном проекте создайте новую группу и назовите ее "Зависимые заголовки" или что-то еще. Теперь в навигаторе проекта перетащите все используемые заголовки из статического проекта в эту новую группу. Во всплывающих опциях я просто оставил его как настройки по умолчанию.
- Вам также может понадобиться связать ваш основной проект с любыми зависимыми библиотеками, используемыми вашей статической библиотекой. Например, моя статическая библиотека использует libxml2 и CFNetwork, и хотя мой основной проект не использует их напрямую, у меня были ошибки компиляции, если я не добавлял их на этапе сборки "связать двоичные файлы с библиотеками".
- Ваш основной проект должен (надеюсь) построить.
Мне действительно не нравятся шаги 8 и 9. Это действительно похоже на то, что XCode не делает то, что рекламируется. Однако, если и когда это будет исправлено, по крайней мере, эти шаги довольно легко отменить, чтобы он работал правильно.
Я думаю, что "неявные зависимости" должны работать без необходимости проходить через шаг 6, может быть, даже шаг 5, но это может быть слишком автоматическим для вкуса многих людей.
Это действительно похоже на ошибку в обработке неявных зависимостей Xcode во время процесса сборки.
В рабочей области с двумя проектами мне удалось увидеть в проекте A классы A в проекте B и успешно создать его, скопировав заголовочные файлы.h для классов проекта B в каталог проекта A. ПРИМЕЧАНИЕ: я не добавил их в проект A в Xcode, я просто поместил их в каталог проекта A в Finder.
Это гораздо более простое решение, чем я видел в общих чертах, так как оно не требует никаких изменений в схемах рабочего пространства или настройках сборки любого проекта. С помощью файлов.h в каталоге проекта A Xcode смог автоматически найти и разрешить все неявные зависимости проекта A от проекта B.
К сожалению, вы не можете поместить файлы.h в их собственный подкаталог с именем "XcodeBugWorkaroundHeaderFiles". Они должны находиться в каталоге, из которого проект уже читает файлы.h. Кроме того, псевдонимы не будут работать, но символические ссылки будут работать, поэтому при использовании SymLink вам не нужно беспокоиться об устаревших копиях.
Учитывая все вышесказанное, я не уверен, что наличие "скрытых".h файлов, без которых сборка не удастся, является хорошей идеей. Пока ошибка не исправлена в XCode, вероятно, лучше всего добавить их в проект, чтобы вы могли видеть их в XCode.
Я получил это на работу, сделав следующее. 1. Добавление библиотеки в качестве второго проекта в рабочую область. 2. Связать двоичные файлы с библиотеками> Добавить статическую библиотеку.
- ВАЖНАЯ ЧАСТЬ -
Добавьте следующее в "Пути поиска заголовка" в настройках сборки
${BUILT_PRODUCTS_DIR}
Это свяжет встроенные заголовочные файлы с проектом. Нет больше ошибок сборки.
Чтобы решить проблемы с пробелами в путях поиска в заголовке пользователя, используйте
"${BUILT_PRODUCTS_DIR}"
Другой вариант - просто включить корень каждого "подпроекта" в качестве рекурсивного пути заголовка. Например, если у вас есть AcmeLib, вы можете перейти к параметрам сборки основного проекта и добавить путь к AcmeLib в Путь поиска заголовка пользователя с включенной рекурсивной опцией. Тогда заголовочные файлы вашей AcmeLib будут автоматически найдены.
Чтобы сохранить независимость пути между разработчиками, вы можете указать путь относительно переменной каталога источника, скажем, $ACME_LIB, которую каждый разработчик может использовать в панели "Источники" настроек XCode.
Поэтому, чтобы использовать AcmeLib в новом проекте, просто перетащите его в проект, добавьте $ ACME_LIB в путь поиска заголовка, и все готово. Неявное связывание XCode должно соединять зависимости.