У меня есть рабочая область Xcode 7.3 с тремя проектами: App, FrameworkA и FrameworkB. Каждый проект имеет одну цель. Это iOS, поэтому целью фреймворка являются Cocoa Touch Frameworks, что означает фреймворки, содержащие динамически связанные общие библиотеки.
Приложение зависит от платформы A, которая зависит от платформы B. Эти зависимости работают, поскольку A правильно связывается с продуктом сборки B, а приложение правильно связывается с обеими платформами A и B и встраивает их (поскольку одна платформа не может встраивать другую). , похоже, пакет приложений должен связать и внедрить как прямые, так и транзитивные зависимости.)
Но вот моя проблема. Фреймворки A и B имеют обычные конфигурации сборки, Debug и Release. Приложение имеет дополнительную конфигурацию сборки, LocalRelease, которая запускается действием «Выполнить сборку» и используется для создания оптимизированной сборки (например, «Выпуск»), но кода, подписанного с идентификатором разработчика (например, «Отладка»).
Когда я пытаюсь собрать приложение с этой конфигурацией сборки LocalRelease, это прерывает сборку, поскольку нарушает зависимости от фреймворков A и B. Я полагаю, что это потому, что эти фреймворки не имеют конфигураций сборки LocalRelease, поэтому Xcode никогда не помещает свои продукты сборки в Папка LocalRelease-iphoneos, как и в App.
Итак, мой узкий вопрос: как мне настроить параметры сборки, чтобы проект с нестандартным именем конфигурации сборки (например, LocalRelease) мог зависеть от других проектов, которые используют только стандартные имена конфигурации сборки? Я надеюсь, что есть простой способ сделать это, не требующий добавления скриптов или файлов xcconfig, но если они необходимы, я хотел бы понять, почему.
И мой более широкий вопрос: вообще плохая ли идея вводить дополнительные конфигурации сборки, потому что они не позволяют плавно взаимодействовать зависимостям между проектами в общем рабочем пространстве? Я был вынужден определить эту третью конфигурацию, потому что мне нужна была оптимизированная локальная сборка, я не хотел определять новую схему и хотел, чтобы выбор типа сборки выражался различными действиями сборки (запуск, профиль, выпуск) единая схема.
Но, возможно, это был неправильный способ сделать это. Поскольку имена конфигураций сборки определяют пути к каталогам продуктов сборки, а зависимые проекты должны находить продукты сборки друг друга в общем каталоге, кажется, что введение в проект нестандартного имени конфигурации сборки нарушит взаимодействие с зависит от других проектов.
