У меня есть рабочая область Xcode 7.3 с тремя проектами: App, FrameworkA и FrameworkB. Каждый проект имеет одну цель. Это iOS, поэтому цели платформы - Cocoa Touch Frameworks, что означает платформы, содержащие динамически связанные общие библиотеки.

Приложение зависит от Framework A, которое зависит от Framework B. Эти зависимости работают, поскольку A правильно связывается с продуктом сборки B, а приложение правильно связывает и встраивает обе платформы A и B (потому что одна платформа не может встраивать другую Похоже, что пакет приложений должен связывать и включать как прямые, так и транзитивные зависимости.)

Но вот моя проблема. Фреймворки A и B имеют обычные конфигурации сборки, Debug и Release. Приложение имеет дополнительную конфигурацию сборки LocalRelease, которая запускается действием «Выполнить сборку» и используется для построения оптимизированной сборки (например, Release), но код подписывается идентификатором разработчика (например, Debug).

Когда я пытаюсь собрать приложение с этой конфигурацией сборки LocalRelease, это нарушает сборку, поскольку она нарушает зависимости на платформах A и B. Я полагаю, что это потому, что эти платформы не имеют конфигураций сборки LocalRelease, поэтому Xcode никогда не помещает свои продукты сборки в Папка LocalRelease-iphoneos, как и в приложении.

Поэтому мой узкий вопрос заключается в том, как настроить параметры сборки, чтобы проект с нестандартным именем конфигурации сборки (например, LocalRelease) мог зависеть от других проектов, которые используют только стандартные имена конфигурации сборки? Я надеюсь, что есть простой способ сделать это, не требующий добавления скриптов или файлов xcconfig, но если они необходимы, я бы хотел понять, почему.

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

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