В Xcode 4 и вложенные проекты - заголовочные файлы не найдены


у меня есть множество проблем с Xcode 4 и вложенными проектами, которые хорошо работали под Xcode 3.2. Вот очень простой, который я не могу решить:

Я создаю структуру cocoa, которая требует другой структуры cocoa, для которой у меня есть источник. Поэтому я выполняю обычные шаги:

  • перетащите .xcodeproj файл необходимого фреймворка в мой основной проект фреймворка
  • в моей основной структуре в разделе Цели > MyFramework > этапы сборки > Целевой Зависимостей: добавьте цель вложенного проекта
  • убедитесь, что заголовочные файлы из вложенной структуры государственной
  • В Настройках Xcode > Locations > Построить Место у меня он установлен до поместите продукты сборки в расположение производных данных (рекомендуется)
  • путь сборки изделий для обеих целей установлено значение ${BUILT_PRODUCTS_DIR} и скажи мне, что они находятся на DerivedData / Debug (или освобождения) расположение
  • параметры архитектуры для обеих целей идентичны

затем я нажал [CMD] + B, чтобы построить, и он говорит мне, что он не находит заголовочные файлы вложенной структуры. Когда я проверяю настройки, Пути Поиска Заголовка Пользователя содержит путь к DerivedData / Debug, а внутри есть вложенный фреймворк target с заголовочными файлами в Versions/A / Headers.

я сижу здесь, кто-нибудь в знаю, что я делаю не так?


проблема уходит при построении для Debug когда я меняю пути поиска заголовка пользователя до ${BUILT_PRODUCTS_DIR}/MyFramework.framework/Headers. Однако это не работает при построении для распределение в качестве фреймворков затем используются их настройки выпуска, которые заканчиваются в другом подкаталоге...


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

8 52

8 ответов:

вот мои синтезированные знания до сих пор:

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

  1. облегчить вашу боль, убедившись, что все цели имеют то же имя для конфигурации сборки (т. е. добавить "AdHoc" и Конфигурация "развертывание" для статических библиотек).

  2. в настройках сборки, точке Пути Поиска Заголовка (если вы используете #include <file.h>) или Пути Поиска Заголовка Пользователя (если вы используете #include "file.h") в каталог проекта статической библиотеки. Если проект статической библиотеки внутри вашего приложения каталог используйте этот:

    "$(PROJECT_DIR)" (рекурсивные включен)

    если у вас есть каталог, который содержит а) проект статической библиотеки и Б) ваше приложение, то это должно работать:

    "$(PROJECT_DIR)/.." (рекурсивные включен)

  3. если подмодуль содержит скомпилированные библиотеки, установить Пути Поиска Библиотеки to:

    "$(TARGET_BUILD_DIR)"

  4. убедитесь, что все статические библиотечные проекты, которые вы используете, имеют Пропустить Установите значение YES.

  5. снова, нет открытых заголовочных файлов (Build Phases " Copy Headers) в любой из статических библиотек, иначе Xcode не сможет архивировать приложение.

  6. обязательно сообщите Xcode, когда создавать статические библиотеки, как показано в этом техническом документе от Apple.


Ответ:

Я до сих пор не нашли реального решения этой проблемы со статическими библиотеками. Что работает для меня это:

  • создайте конфигурацию "AdHoc" для статической библиотеки
  • добавить $(BUILT_PRODUCTS_DIR) в пути поиска заголовка пользователя для приложения (с рекурсивные проверено) -> это используется при запуске приложения
  • в меню Xcode, выберите продукт>Построить>Сборка Для Архивирования

это работает, приложение находит заголовочные файлы и строит себя, она заканчивается в DerivedData//строительства/продукты/нерегламентированном-троянца iPhoneOS/ как пакет приложений. После эти простые инструкции (мертвая ссылка) от TestFlightApp.com я могу упаковать это приложение в IPA и отправить его вокруг. Просто выбрав архиве приложение из Xcode снова не находит заголовки, даже если они действительно находятся в каталоге сборки AdHoc-iphoneos.

(начиная с Xcode 5.1)

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

$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include

к "пути поиска заголовка" для схемы, которую вы используете для архивирования.

Если вы не уверены, какая схема используется для архивирования, перейдите в раздел продукт - > Схема - > редактировать схемы и искать архив в левой колонке.

убедитесь, что ваш сторонний фреймворк добавлен как "группа" в ваш основной проект, чтобы вы могли видеть его в иерархии вашего проекта...

У меня была такая же проблема здесь, и я мог бы решить эту проблему, установив "Build Location" для размещения продуктов сборки в местах, указанных целями"

У меня была эта проблема: я мог создавать как конфигурации Debug, так и App Store, но не Ad Hoc. Строительство Ad Hoc дало мне ошибки, потому что он не мог найти .H файлы, необходимые для вложенных проектов.

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

Мне потребовалось несколько часов, чтобы понять это! Мой разум просто не прыгнул с места недостающий.H файлы для подготовки ошибок просто сами по себе. = ) Возможно, была ошибка или предупреждение, жалующееся на недостающее обеспечение, но если это так, то оно было хорошо похоронено среди сотен .H связанных ошибок.

У меня была такая же проблема с конфигурацией с именем "ad Hoc" (согласно рекомендации TestFlight по адресу http://help.testflightapp.com/customer/portal/articles/402782-how-to-create-an-ipa-xcode-4) и основной проект не смог найти некоторые заголовки из вложенных проектов. Я переименовал проект в "AdHoc" (без пробелов) , и проблема ушла; похоже, что в некоторых случаях пробелы могут испортить пути поиска заголовка, хотя я не выяснил специфику, когда это может случиться и почему.

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

http://developer.apple.com/library/ios/#DOCUMENTATION/Xcode/Conceptual/ios_development_workflow/AA-Developing_a_Static_Library_and_Incorporating_It_in_Your_Application/archiving_an_application_that_uses_a_static_library.html

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

для меня это произошло после слияния GIT, которое создало много конфликтов, один из которых связан с файлом проекта. После слияния, я уверен, что структура файла проекта изменилась.

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

Я думаю, слияние превратило это логическое значение в No, поэтому проект не искал в нужных местах для заголовка файлы.