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

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

Пример рабочего пространства: DependenciesInXcode4.zip

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

Build Failed

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

Build Errors

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

Manual Linking

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

Manually Reference Headers

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

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

Я был бы признателен за помощь в понимании того, как заставить "неявные зависимости" работать с рабочими пространствами в Xcode 4.

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

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

ОТВЕТЫ

Ответ 1

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

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

  • Создайте новое рабочее пространство в Xcode.
  • Добавить новый проект в рабочую область для вашей статической библиотеки. Вы также можете добавить существующий проект, я нашел, что это тоже работает.
  • Проверьте, что библиотека построена так, как ожидалось.
  • Добавить новый проект в рабочее пространство для вашего основного проекта. Снова мне удалось добавить существующий, но важно, чтобы у него не было никаких настроек сборки, которые были связаны с библиотекой. Если вы добавите новый проект, достаточно просто добавить к нему существующие исходные файлы. Моя особая ситуация осложнялась очень большим уже существующим хранилищем SVN, который я не хотел реструктурировать.
  • На этом этапе я собираюсь предположить, что ваш исходный код уже содержит импорт заголовков из статической библиотеки.
  • На этапах сборки основного проекта разверните раздел "link binary with libraries" и щелкните символ+. Выберите цель из проекта статической библиотеки.
  • Если вы хотите на этом этапе, вы можете создать основной проект, чтобы подтвердить, что он не работает, как показано на снимках экрана OP с ошибками "Нет таких файлов..." для импорта заголовков.
  • Теперь это бит, который мне не очень нравится. В своем основном проекте создайте новую группу и называйте ее зависимыми заголовками или что угодно. Теперь в навигация по проекту перетащите все использованные заголовки из вашего статического проекта в эту новую группу. В появившихся опциях я просто оставил его как настройки по умолчанию.
  • Вам также может потребоваться связать ваш основной проект с любыми зависимыми библиотеками, используемыми вашей статической библиотекой. Например, моя статическая библиотека использует libxml2 и CFNetwork, и хотя мой основной проект не использует их напрямую, у меня были ошибки компиляции, если я не добавлял их в фазу сборки "link binary with libraries".
  • Теперь ваш основной проект должен (надеюсь) построить.

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

Ответ 5

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

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

  • Добавьте следующие параметры в "Пути поиска заголовков" в настройках сборки

    ${BUILT_PRODUCTS_DIR}

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

Ответ 6

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

"${BUILT_PRODUCTS_DIR}"