Обзор

Я использую статические библиотеки и рабочие пространства Xcode 4 для обеспечения модульности в разработке iOS - все более распространенная техника. Например, у меня может быть рабочее пространство, содержащее проект App и проект Library, вот так¹:

Затем у вас будет схема сборки этих проектов, которая будет выглядеть примерно так:

Что я хотел бы сделать, так это чтобы "сборка App" контролировала инициируемую ею "сборку Library", по крайней мере, несколькими способами:

1. Map App configurations (e. например, Debug, AdHoc) к произвольным конфигурациям библиотеки

2. Передача некоторого подмножества определений -D, и/или указание их для сборки библиотеки.

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

Разъяснения

• Я использую App/Library здесь как простую опору для любых отношений между суперпроектом и подпроектом, которые у вас могут быть.

• Из того, что я видел, встроенные подпроекты в стиле Xcode 3, похоже, не работают в Xcode 4 иначе, чем "коллеги" рабочего пространства. Я был бы рад ошибиться в этом.

• Я знаю, что могу сделать практически все, что угодно, используя фазу сборки "Run Build Script" и xcodebuild. Но я пытаюсь работать в рамках системы, где зависимости указаны в схеме, а в остальном они несколько слабо связаны.

• Библиотека существует для использования не только в этом проекте, и поэтому вы не можете произвольно нагружать ее хламом, специфичным для сборки этого приложения, или ссылаться на что-то специфичное для приложения или рабочего пространства. Для общего случая это исключает включение статических .xcconfig из проекта App как способ передачи информации о сборке из App в библиотеку.

• Создание библиотеки вне рабочего пространства приносит слишком много жертв, это не вариант.

Сопоставление конфигураций

Как я понимаю, сборка определенной конфигурации App будет:

1. Если в библиотеке существует конфигурация с таким же именем, она будет собирать библиотеку, используя ее.
2. В противном случае будет собрана активная конфигурация библиотеки, как указано в файле проекта библиотеки.

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

В идеале, я бы мог указать (в схеме, предположительно):

AppConfigA -> LibConfig1
AppConfigB -> LibConfig2

Хотя Debug, AdHoc и Release могут быть единственными конфигурациями, которые некоторые когда-либо используют, сложные проекты часто перерастают это.

Определения

Я пока не нашел способа передать -D определения из сборки App в библиотеку, не прибегая к xcodebuild, который может принимать, например, файл .xcconfig.

Доступ к настройкам сборки App можно получить на этапе выполнения скрипта run-build-script сборки Library. Однако это вводит зависимость в библиотеке от проекта App, что по уважительной причине запрещено (см. Разъяснения). Но даже тогда я не нашел способа использовать эти настройки для прямого управления сборкой Библиотеки (much²).

Так что это просто безумие...

Одна схема, которую я придумал, пока писал это, была бы такой:

1. Библиотека основывает свои конфигурации сборки на пустом (фиктивном) LibraryExternals.xcconfig файле внутри собственного проекта.

2. Очистка Библиотеки удаляет этот файл. Автономная сборка Библиотеки создаст пустой файл, если он еще не существует.

3. Этот файл перезаписывается во время фазы App Build run-build-script и содержит все, что приложение хочет сообщить сборке Библиотеки.

Кажется сложным, но я сейчас ищу все, что угодно. Я добавлю это в ответ, если не появится ничего лучшего.

¹ Приложения показаны для Max OS X. Я считаю, что приложения командной строки делают более простые тесты. То же самое.

² Ср. препроцессинг Info.plist, о котором я узнал во время этого исследования.