Настройки сборки версий XCode на платформах
Я работаю над платформой iOS на основе следующего шаблона: https://github.com/jverkoey/iOS-Framework
Теперь мне нужно немного отполировать и настроить систему управления версиями с соответствующим номером сборки / маркетинга.
Этот каркасный проект имеет 3 цели: 1-ю, которая генерирует статическую библиотеку, 2-ю, которая генерирует пакет ресурсов, и 3-ю цель, которая является совокупной целью для статической библиотеки и пакета ресурсов. Поэтому моя первая проблема заключается в том, чтобы определить, для какой цели мне нужно настроить параметры сборки управления версиями (или мне нужно настроить все цели).
Мой второй вопрос: какие настройки я должен настроить и что они означают:
Текущая версия проекта => Это версия сборки или маркетинговая версия? Так что, если я выпускаю приложения с такими версиями, как: 1.2.3.4, я должен установить 4? или 1.2.3? или 1.2.3.4?
Имя сгенерированного источника версий => Имя сгенерированного файла.c, который содержит целое число сборки?
Сгенерированные переменные управления версиями => Что это?
Префикс названия версии => Префикс для имени переменной, содержащей номер сборки
Суффикс имени версии => Суффикс для имени переменной, содержащей номер сборки
Система управления версиями: все используют Apple Generic, поэтому я думаю, что это единственный доступный
Имя пользователя: что это?
Есть другие параметры, такие как "Версия платформы" в разделе "Упаковка", которые всегда должны использовать "A", я думаю, на iOS (так как они на самом деле являются статическими структурами, версия не имеет значения)? А для параметров "Версия совместимости" / "Текущая версия библиотеки" раздела "Связывание" следует ли настраивать их только для статической целевой библиотеки? или они используются приложением, связывающим библиотеку?
2 ответа
Если вы не создаете коммерческий фреймворк с закрытым исходным кодом, я бы действительно рекомендовал использовать CocoaPods. Он позаботится о зависимостях, ресурсах, управлении версиями, обновлении, установке и т. Д. Все большие головные боли по мере изменения вашей библиотеки со временем.
Даже если вы хотите распространять двоичные файлы только для закрытого исходного кода, вы можете создать двоичные файлы с помощью CocoaPods, а затем распространять их с другим podspec. Также вы избежите встраивания кода других библиотек, что является очень плохой, но обычной практикой.
Что касается версий, вы можете проверить здесь.
Возвращаясь к созданию статической библиотеки...
Версия не видна из приложения и будет просто документацией, поэтому я думаю, что вы должны добавить ее ко всем своим целям. Если вы действительно хотите иметь возможность определять версию вашей библиотеки во время выполнения, вам нужно придумать метод класса или глобальную переменную, такую как [MyLibrary version],
Документация для этих ключей включена в XCode, или вы можете просто выбрать один и проверить панель "Quick Help":
У Apple есть довольно обширная документация по созданию и распространению фреймворков.
Руководство по программированию Framework охватывает большую часть необходимых вам оснований. Если вы хотите получить более конкретную информацию о том, как инструменты разработчика используют информацию в вашем проекте, посмотрите страницу руководства для agvtool, инструмент, который Xcode использует с системой контроля версий apple.
Вы также должны быть заинтересованы в Руководстве по кодированию для какао, которое также охватывает некоторые передовые практики для платформ.