С++ Build Systems - Что использовать?

Я ищу запуск нового проекта на С++ - только в свое время изначально - и я изучаю доступные системы сборки. Казалось бы, ответ "Многие, и все они ужасные".

Функции, которые мне особенно нужны, следующие:

  • Поддержка С++ 11
  • Кросс-платформа (Linux как главная цель, но способная работать как минимум с Windows)
  • Поддержка достойного тестирования модулей.
  • Поддержка нескольких модулей для разделения кода
  • Поддержка генерации кода (с использованием asn1c или protobuf - еще не на 100%)
  • Простота обслуживания

Теперь я знаю, что я могу сделать 1-4 из тех, кто использует CMake и Autotools достаточно легко. Вероятно, также со Сконсом и Вафом и с другими. Проблема в том, что я никогда не разрабатывал, как правильно генерировать код, используя их, - это исходные файлы, которые не существуют до тех пор, пока процесс сборки не будет запущен, поэтому исходные файлы, которые система сборки должна иметь возможность конвертировать в исполняемый код но на самом деле не знает о том, до начала сборки... (ASN1C, в частности, генерирует десятки заголовков и исходных файлов, которые должны работать вместе, а фактический набор файлов зависит от содержимого вашего asn файла). также тот факт, что ни один из них не особенно удобен в обслуживании - у CMake и Autotools есть свой собственный огромный набор сценариев, которые вам нужно для управления, чтобы они работали, а Waf и Scons требуют, чтобы любой, кто работает с ними, имел приличное знание python (I не надо) работать с ними...

Итак - какие системы сборки рекомендуются для чего-то подобного? Или я буду застрять с файлами make и shell-скриптами?

ОТВЕТЫ

Ответ 1

+1 для "Многие, и они ужасные".

Но "самый богатый" и "самый масштабируемый", вероятно, CMake, который является генератором Makefile (также генерирует собственный MSVС++ *.proj/*.sln). Странный синтаксис, но как только вы его узнаете, он может позволить вам красиво генерировать сборки для разных платформ. Если я "начал-свежий", я бы, вероятно, использовал CMake. Он должен обрабатывать ваш список, хотя ваше "генерация кода" может занять "жизненную жизнь" вне системы сборки в зависимости от того, что вы хотите сделать. (См. Ниже.)

Для простых проектов генератор QMake в порядке (вам не нужно использовать библиотеки Qt для использования QMake). Но вы не описываете "простые" - генерация кода и "дополнительные фазы" означает, что вы, вероятно, хотите CMake или что-то с богатым API для своих собственных расширений, например Scons (или Waf).

Мы используем Scons на работе. Он производит "пуленепробиваемые сборки", но он очень медленный. Никакая другая система не будет такой же пулевой, как Scons. Но это медленно. Он написан на Python, и мы расширили интерфейс для нашей "рабочей области-организации" (где мы просто указываем зависимости модуля), и это часть намерения дизайна Scons (этот тип расширения через Python). Удобно, но сборки медленны. Вы получаете пуленепробиваемые сборки (любой ящик для разработчиков может сделать окончательный выпуск), но он медленный. И это медленно. Не забывайте, что если вы используете Scons, тем не менее, это замедляется. И это медленно.

Мне тяжело думать, что через десять лет после 2000 года у нас все еще нет летающих машин. Нам, вероятно, придется подождать еще сто лет или что-то сделать. И тогда мы все, вероятно, будем летать в наших летающих машинах, которые все еще строятся с помощью crappy build systems.

Да, они все ужасно.

[ОБ ОБЩЕМ КОДЕКСЕ]

Scons работает над "фазами", и они "несколько статичны". Он может создавать код, который генерируется как часть сборки (люди делают это несколькими путями), но это было описано как "что-то очень не похожее на Scons".

Если это простой "препроцессор некоторых файлов и генерировать исходные файлы", то нет biggie (у вас много опций, и именно поэтому qmake был написан - для moc предварительной обработки файлов *.hpp/*.cpp).

Однако, если вы делаете это в "тяжелой манере", вам понадобится script свой собственный. Например, у нас были сценарии "как часть сборки", которые запрашивали базы данных и генерировали классы С++ для взаимодействия между "слоями" (в традиционной разработке приложений на 3 уровня). Аналогично, мы создали исходный код сервера/клиента через IDL и информацию о встроенной версии, позволяющую одновременно запускать несколько клиентов/серверов с разными версиями (для одного и того же "клиента" или "сервера" ). Много сгенерированного исходного кода. Мы могли бы "притворяться", что это "система сборки", но на самом деле это нетривиальная инфраструктура для "управления конфигурацией", частью которой является "сборка". Например, эта система должна была, "сбрасывать" и "запускать" серверы, как часть этого процесса. Аналогичным образом, регрессионные тесты выполнялись как часть этого процесса с тяжелыми "отчетами" и "различиями" между версиями - все это как часть наших "скриптов сборки".

Ответ 2

Теперь вы можете использовать Gradle: https://docs.gradle.org/current/userguide/native_software.html

Это, кажется, созрело совсем немного за годы, так как я изначально разместил это. Страница, в которой говорится о том, что проект "инкубирует", исчез, но я не могу найти официальное объявление, удаляющее этот статус.

Ответ 3

Недавно я узнал об этом, я лично их еще не использовал:

Ninja, небольшая система сборки, ориентированная на скорость. Google теперь использует Ninja для сборки Android вместо Make: ссылка.

Shake - мощная и быстрая система сборки.

Tup - высокопроизводительная система сборки. Алгоритмический дизайн на основе. Анализ Tup.

Все теперь кросс-платформенные и поддерживают Windows. Я еще не уверен в отношении остальных ваших требований, так как, опять же, мне еще предстоит проверить их самостоятельно. Они используются в коммерческой разработке, CIG выбрали ниндзя. Первые два сродни Scons, Ant и т.д.

Ответ 4

Scons - очень дружелюбная и гибкая система, но вы правы, Лотар, это очень медленно.

Но есть способ увеличить производительность программ, написанных на Python. Это использование JIT. Из всех известных проектов PyPy - очень мощная, быстрорастущая и мотивированная реализация JIT-Python 2.7. Совместимость PyPy с Python 2.7 просто потрясающая. Тем не менее, Scons объявлен как неподдерживаемый проект на вики совместимости PyPy. Waf, с другой стороны, смоделированный как suutor autotools на основе python, полностью поддерживается инфраструктурой PyPy. В моих проектах скорость сборки увеличилась в 5-7 раз при переходе на PyPy. Вы можете увидеть отчеты о производительности от PyPy.

Для современной и относительно быстрой системы сборки Waf - хороший выбор.

Ответ 5

Я использовал SCons и впечатлен этой системой сборки. SCons можно расширить с помощью python и python - это здорово, потому что у Python есть все, что вам нужно, просто закодируйте логику, все низкоуровневые функции уже реализованы в SCons и Python и являются кроссплатформенными. Если у вас хорошие навыки программирования, ваши скрипты сборки будут выглядеть идеально и легко.

Make, CMake и подобные системы сборки выглядят как мусор макросов. Waf является аналогом SCons. Я пытаюсь использовать Waf, но Сконс ​​будет более дружелюбным, поэтому я остался с SCons.

По мнению толпы SCons слишком медленный, но в середине проекта я не видел никакой разницы между make и SCons по скорости сборки. Вместо этого, SCons хорошо работал с параллельными сборками, в то время как у Make были большие проблемы с ним.

Кроме того, SCons позволяет вам получать - настраивать, создавать, развертывать, генерировать конфигурацию из шаблонов, запускать тесты и выполнять любую другую задачу, которая может быть выполнена, может кодировать с помощью python и SCons - все в одном. Это очень большое преимущество.

Для простого проекта CMake также является хорошим выбором.

Ответ 6

Система сборки Google - хорошая альтернатива: http://bazel.io/

Ответ 8

Вы можете использовать Ceedling. Обратите внимание, однако он поддерживает только C на данный момент и тесно связан с авторами Unity и CMQ.

Он может быть разветвлен и изменен для работы с компилятором С++ и модульным тестированием/издевательской структурой довольно легко.

Также Tup является достойным упоминанием. Это очень быстро, но он ничего не знает о тестировании фреймворков и т.д., Что означает, что вам придется писать свою собственную систему сборки с помощью Tup. Если вы планируете делать TDD, Tup, вероятно, это путь.