Как эффективно выполнять кроссплатформенные сборки

#ant #msbuild #build

#ant #msbuild #сборка

Вопрос:

Я настраиваю систему сборки для команды, которая создает API, используемые на нескольких платформах и архитектурах. Уже было потрачено много работы на настройку Ant для сборки всего кода Java, поэтому я бы предпочел придерживаться Ant, если это возможно.

Где я в тупике, так это как создавать программное обеспечение на C . Вот платформы и языки, которые мне нужно поддерживать:

  • Java — Linux — 32bit amp; 64bit: Ant
  • Java — Windows — 32bit amp; 64bit: Ant
  • C — Linux — 32bit amp; 64bit: Ant с CPP-задачами (вопрос № 1)
  • C — Windows — 32bit: (вопрос № 2)

Примечание: C в Windows — это проекты MS Visual Studio на C .

Я думаю, что ответом на вопрос № 1 является CppTasks, потому что это, похоже, стандартный способ сборки C из Ant.

Что касается вопроса № 2, я мог бы также использовать CppTasks, но разработчики будут компилироваться в Visual Studio, поэтому представляется выгодным использовать их проект Visual Studio для сборки, что означает вызов MSBuild из Ant.

Кто-нибудь пробовал это раньше и у него есть хорошее решение для сборки Java amp; C как в Linux, так и в Windows?

Ответ №1:

Используете ли вы систему непрерывной сборки, такую как Jenkins?

С помощью Jenkins ваши сборки могут автоматически запускаться при регистрации / фиксации, времени суток и / или по команде. Самое замечательное в Jenkins то, что вы можете заставить его автоматически создавать все различные версии вашего программного обеспечения.

Например, вам, вероятно, потребуется работать make на Linux C , но использовать msbuild в системах Windows, и вам нужно будет запустить сборку на компьютере с Linux и одну для компьютера с Windows. Дженкинс может быть настроен на автоматическое выполнение. Когда происходит фиксация, все ваши различные сборки на всех ваших системах могут быть запущены одновременно. Затем вы можете сохранить нужные вам сборки в Jenkins, и ваши пользователи фактически извлекут нужный им тип из нужного им проекта.

Существует множество способов настройки, но самый простой — просто создать четыре отдельных задания (по одному для Java 32bit, Java 64bit, C Linux и C Microsoft). Вам необязательно нужна отдельная сборка Microsoft Java (по крайней мере, теоретически), но вас ничто не останавливает.

У вас может быть один сервер Jenkins, выполняющий «подчиненные» задания в других системах сборки, так что вы могли бы заставить Jenkins работать в 64-разрядной системе Linux, но использовать 32-разрядную систему Linux в качестве подчиненной для выполнения 32-разрядной сборки и вызывать подчиненную систему Windows для выполнения сборки Visual Basic. Таким образом, все ваши задания располагаются в центральном месте, но вы можете использовать те среды, которые хотите.

Если вы никогда не использовали систему непрерывной сборки, скачайте Jenkins и поиграйте с ней. Это бесплатно с открытым исходным кодом и очень, очень просто в использовании. Вы можете запустить его на любой машине, на которой установлен JDK или JRE 1.6. Если вы загружаете версию для Windows, она даже поставляется с уже встроенной JRE.

Лучше всего использовать систему непрерывной сборки и позволить ей справляться с беспорядком. Кстати, есть также Bamboo, CruiseControl и Hudson (который был отделен от Jenkins несколько месяцев назад)

Комментарии:

1. В итоге у нас получился единый фреймворк Any build, который использует cpptasks для выполнения сборок gcc и msbuild и настроен для запуска на подчиненных устройствах Linux и Windows через Hudson. Это работает довольно хорошо, но по-прежнему существует приличный объем накладных расходов на поддержку различных конфигураций.

Ответ №2:

TeamCity должен очень хорошо соответствовать всем требованиям. Он поддерживает Ant и MSBuild изначально и имеет довольно хорошую кросс-платформенную историю (написанную на Java, но отличную интеграцию, например, с Win).

Не вижу никакой пользы в том, чтобы переносить сборки на основе Win MSBuild в еще одну систему сборки.

Ответ №3:

Список для этого выглядит немного по-другому (на мой взгляд)

Комментарии:

1. В Ant слишком много существующей инфраструктуры, поэтому переход на Maven был бы слишком дорогостоящим.