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

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

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

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

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


continuous-integration c++ build-automation build-server
person Joe    schedule 02.11.2010    source источник
comment
Хотелось бы увидеть хороший ответ на этот вопрос. В дополнение к исходному вопросу, я хотел бы знать, как я могу кросс-компиляцию для mingw в Linux (я использую mingw в Windows). Также я использую Qt framework и QTestLib для модульного тестирования. Спасибо!   -  person Etienne Savard    schedule 13.05.2011
comment
Я тоже хотел бы увидеть хороший ответ на этот вопрос. IMHO, это касается проблем управления конфигурацией, поскольку каждый модуль соединяется с другими модулями, и, связывая библиотеку, это означает, что вы неявно должны связать библиотеки восходящего потока. Поскольку для этого требуются ограничения-версии библиотеки, эта проблема быстро усложняется (например, DLL-hell или RPM-hell). Косвенное распространение зависимостей необходимо в контексте ограниченных совместимых версий.   -  person charley    schedule 13.05.2011

Ответы (3)


arrow_upward
6
arrow_downward

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

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

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

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

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

person user258808    schedule 17.05.2011
comment
Как вы думаете, я мог бы добиться чего-то подобного, используя qmake вместо CMake (сейчас мы используем qmake, а до этого мы использовали Scons)? - person Etienne Savard; 19.05.2011
comment
Я не использовал qmake, поэтому не могу точно сказать, как он будет работать. Здесь находится ссылка, в которой рассказывается о кросс-компиляции приложений Qt для Windows в Linux с помощью qmake. Scons тоже очень хорош, я пробовал, прежде чем выбрать CMake. Мы выбрали CMake, потому что он поддерживает несколько IDE. У нас есть люди, использующие Eclipse, Code :: Blocks, VS05, VS10 и Emacs. Единственные проблемы, с которыми я столкнулся, заключались в поддержке предварительно скомпилированных заголовков с помощью CMake. - person user258808; 19.05.2011

arrow_upward
4
arrow_downward

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

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

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

person Paul Rubel    schedule 02.11.2010

arrow_upward
0
arrow_downward

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

Я хотел бы сделать этап тестирования автоматизированным, но мне еще не дали на это времени.

person Phil Hannent    schedule 19.05.2011