У нас сложная кодовая база C ++, предназначенная для нескольких мобильных платформ.В настоящее время у нас есть Windows CE (от 4,2 до 6,5 как сырой CE и Mobile на их основе), Android (2,1+), iPhone (4+), почтиработает Bada (2.0+) и, если что-то выйдет из нового C ++ / CX, скорее всего, добавит Windows Phone (8+).Плюс тестовая версия на Win32 и приложение-служба на Win64, которое разделяет некоторый код.Мы также уже пытались скомпилировать модульные тесты для Linux, и уже пришли вопросы (пока слишком малый объем бизнеса, но это может измениться), чтобы заставить его работать на некоторых других платформах Linux.
В настоящее время мы компилируем код с использованием nativeинструменты для каждой платформы.Каждый из них является довольно сложным и имеет несколько хаков в нем или вокруг него для достижения разумных сборок одним кликом.А для Bada мы еще не решали сборки вне Eclipse, настроенного Samsung, что нам придется делать для производства.
Пока это работает, но становится все более и более сложной задачей для обслуживания,Самая большая проблема в настоящее время - это сборка iPhone, потому что в отличие от файлов проекта Visual Studio и простых make-файлов, невозможно вручную добавлять / удалять / переименовывать файлы в проекте XCode, и только у двух человек есть MacOS boxen и любой опыт работы с XCode (в то время как у всех естьWindows и знает Visual Studio).Нам также нужно создать несколько make-файлов для цели Bada (это простой набор инструментов GNU, так что все, что может кросс-компилировать с ними, должно быть), и я бы не стал избавляться от некоторых ошибок в сборке Android: исправление ошибки вобработка зависимостей при сборке под cygwin, некоторые хаки поверх скрипта сборки ant и клей оболочки для массажа манифеста и удержания всего этого вместе.
Поэтому я ищу советы о том, как унифицировать процесс сборки для этого набораразнообразных платформ.
- Это абсолютно необходимо для сборки исполняемых файлов iPhone и Bada, а также для встроенной части сборки Android (поскольку никто не может тестировать все три платформы отдельно).
- Должен обрабатывать большой проект, состоящий из нескольких общих библиотек, одного основного двоичного файла, одного тестового двоичного файла для тех же платформ и некоторых вспомогательных двоичных файлов, созданных только на некоторых платформах (ну, в настоящее время только Win32).
- Должен быть в состояниисоздать заголовок конфигурации сборки и файл Java с версией from система контроля версий и некоторые пользовательские переменные, поскольку мы делаем 18 и считаем несколько разных сборок для разных клиентов.
- И, конечно, он должен автоматически обрабатывать зависимости (заголовочные файлы) и в целом быть надежным.
Что касается других вещей, я готов разобраться с любыми недостатками, но я, очевидно, хотел бы свести количество оболочки клейкой ленты и сплюнуть к минимуму, поэтому он должен:
- Уметь интегрироваться с Visual Studio, Eclipse и XCode настолько, чтобы каждая среда могла запускать сборку, загружать продукт сборки в соответствующую цель и подключать к ней отладчик.
- Уметь создавать Java и вызывать пользовательскиеинструменты упаковки для Android, поэтому нам не нужно взламывать скрипт сборки Ant, который Google безвозмездно и несовместимо дважды менял за последние два года (и старый SDK не может быть загружен).
- Уметьустановить различные файлы данных и вызвать случайные упаковщики и другие случайные сценарииd инструменты и прочее, поэтому его не нужно смешивать со слишком большим количеством сценариев оболочки.
Мы до сих пор начали пытаться CMake (не было много времени, поэтому не ушел далеко, но скоро придется что-то делать), а также подумал о SCons, Однако несколько лет назад я уже пытался создавать с помощью SCons для Windows CE, но, поскольку он генерирует проекты типа makefile для Visual Studio, а те не работали для встраиваемых платформ в VS2005, я отказался. CMake может генерировать собственные make-файлы, но для CE требуется ветвь , немного устаревшая, ветвь . Поэтому я хотел бы спросить, есть ли какие-либо другие инструменты, которые мы могли бы рассмотреть, или какие-либо известные камни преткновения с этими инструментами, о которых мы должны знать .
Обновления: Я нашел инструкции для собственных двоичных файлов Android в нескольких местах, а pixellight даже имеет скрипт cmake для генерации apk, напрямую вызывая инструменты упаковки. Также этот сценарий оболочки показывает это. Использование iPhone здесь, похоже, задокументировано.