Сервер непрерывной интеграции для C ++. Как насчет библиотечных зависимостей?

Question

В настоящее время я изучаю хорошую настройку для сервера непрерывной интеграции, который бы создавал различные приложения C ++ для нескольких дистрибутивов Linux.

Мой основной вопрос заключается в том, как другие пользователи здесь обрабатывают различия в системных библиотеках между дистрибутивами Linux.?

Хотя может быть относительно легко создавать прямые зависимости, такие как библиотеки пользовательского интерфейса, вместе с приложением, «косвенные» зависимости, такие как glibc, выглядят как большая боль, если их приходится каждый раз создавать вместе с приложением.Поэтому я думаю о переносе фактического выполнения сборки в отдельную виртуальную машину для каждого дистрибутива, например, используя rlogin для запуска команд.Моя цель состоит в том, чтобы предотвратить двоичные несовместимости между версиями библиотеки сборки-машины и версиями, развернутыми в целевых дистрибутивах.

Кто-нибудь здесь имеет какой-либо опыт с таким процессом и может сказать, звучит ли приведенный выше вариант как выполнимый подход?

Answer 1

Мы используем Jenkins (непрерывная интеграция) и CMake (система сборки) для этой цели.Дженкинс похож на Buildbot, то есть у него есть buildmaster и buildslaves.В настоящее время я настроил 8 подчиненных для сборки на 4 разных платформах (FC8, FC10, FC12 и Windows 7).Мы собираем как отладочные, так и выпускные двоичные файлы, поэтому я выделил по одному ведомому устройству для каждой платформы и типа сборки.

Что касается сторонних библиотек, таких как Qt & Boost, я скомпилировал их на каждой платформе и проверил их в отдельном репозитории.

@ esavard: Мы используем CMake 2.8 для кросс-компиляции, яЯ не использовал Minigw, но быстрый поиск в Google показывает, что это возможно.Вот ссылка на учебник по кросс-компиляции для Windows в Linux с использованием CMake и miniGW.

Я не использовал Buildbot и не могу комментировать его возможности, но подумал, что должен упомянуть альтернативув настоящее время мы используем.

Надеюсь, это поможет.

Answer 2

Buildbot имеет понятие buildmasters и buildslaves .

Мастер сборки заботится об отображении веб-интерфейса, отправке электронной почты, запуске сборок и других служебных задач.Ведомые сборщики ждут мастера сборки и по команде выполняют сборку.

У нас есть buildbot, настроенный для работы на нескольких различных платформах, некоторые из которых являются виртуальными машинами, и он хорошо работает для нас.

Answer 3

Конечно, buildbot и многие виртуальные машины - это путь для этого. У нас есть сервер VMWare ESX, на котором размещено много ведомых сборок, которые в одночасье компилируют наше приложение. Затем приложение тестируется на другой виртуальной машине (не на ведомой сборке и просто с установленной ОС по умолчанию), чтобы убедиться, что оно работает и все зависимости упакованы.

Хорошо, что я хотел бы сделать, чтобы сделать этап выполнения тестирования автоматизированным шагом, но у меня еще не было времени сделать это.