Сервер непрерывной интеграции для С++ - Что относительно зависимостей библиотек?

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

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

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

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

Ответ 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 и не могу комментировать его функции, но думал, что должен упомянуть альтернативу, которую мы сейчас используем.

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

Ответ 2

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

Строитель позаботится о отображении веб-графического интерфейса, отправке электронной почты, запуске сборок и других домашних заданий. Buildslaves ждут от buildmaster и когда команда будет выполнять сборки.

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

Ответ 3

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

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