SCons или CMake вместо qmake

Мне нужен совет по следующему вопросу:

У меня есть проект QT, который в настоящее время настроен для работы с qmake. Однако из-за расширения требований и будущих направлений проекта мне нужно изменить систему сборки, поскольку приложение потребует некоторых изменений в том, как он будет построен.

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

Но направление, к которому я стремлюсь, - это модульное приложение таким образом, чтобы каждая "функция" была скомпилирована в общую библиотеку, и пользователь (разработчик) сможет выбрать компоненты, которые он хочет скомпилировать. Эти "функции" помещаются в каталоги в исходном дереве (например: query_builder, reverse_engineer, mysql_DB_support, директории version_managemen и т.д.), А когда пользователь создает приложение, он просто сообщает системе сборки компилировать приложение с построителем запросов, и mysql, но без обратной инженерии, и в этом случае система сборки добавляет исходные файлы из указанного каталога и создает из нее lib.

У меня также есть другие требования, такие как:

  • windows build, linux build
  • возможность сборки пакета (deb, rpm)
  • поддержка QT и, возможно, QT5
  • несколько исполняемых файлов (клиент GUI, клиент CLI)

После некоторых "маркетинговых исследований" я столкнулся с CMake и SCons как двумя возможными системами, которые я мог бы использовать. У меня есть опыт CMake и некоторый опыт python, но пока нет SCons.

Но я не знаю, какой из них лучше для моего дела, вот где мне нужна ваша помощь. Не могли бы вы уточнить, что я должен использовать? И если вы считаете, что мои требования достижимы с помощью qmake, пожалуйста, сообщите мне об этом,

Cheers, е.

ОТВЕТЫ

Ответ 1

Нет правильного ответа на этот вопрос, и он обычно сводится к личным предпочтениям, вроде как vi против emacs (правильный ответ - vi, конечно:)

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

Я частично отношусь к SCons, главным образом потому, что я не могу синтаксис CMake, но это личное предпочтение. Вот некоторые плюсы и минусы каждого, как я вижу:

CMake

Плюсы:

  • Подобно QMake, учитывая, что это генератор makefile
  • CMake широко используется, поэтому есть много ссылок и доступных справок.
  • Имеет графический интерфейс (я сам не знаю его, основываясь на комментариях Calvin1602 ниже).

Минусы:

  • У CMake есть свой собственный, изобретенный синтаксис, который многие считают (включенным мной) неинтуитивным.
  • 2-этапный процесс сборки, сначала создайте Make файлы, а затем выполните компиляцию
  • Невозможно прочитать сгенерированные Makefiles

SCons

Плюсы:

  • Синтаксис - это Python, который широко используется и относительно легко учится. (и Python классно:)
  • Процесс сборки - это один шаг, просто выполните SCons, и он скомпилируется. Нет промежуточных файлов сборки для создания или поддержки.
  • В прошлом SCons был медленнее, чем CMake, но с тех пор он намного быстрее, вероятно, так же быстро или быстрее, чем CMake, поскольку он не должен генерировать make файлы.
  • Богатый набор функций и поддержка многих языков, тогда как CMake ориентирован на C/С++
  • Очень точная система неявных зависимостей: нет необходимости явно перечислять зависимые заголовки, библиотеки и т.д. При необходимости могут быть указаны явные зависимости.
  • Доступен плагин eclipse. Eclipse также имеет плагины для Python.
  • Были ли созданы инструменты для проектов Qt для обработки MOC и других связанных с ними кодегенов, как указано здесь.

Минусы:

  • SCons не может быть так широко распространен, как CMake, но есть еще много поддержки.
  • В зависимости от размера проекта, SCons может использовать много памяти, поскольку он анализирует все скрипты сборки и строит дерево зависимостей в памяти, прежде чем компилировать что-либо. Это позволяет, однако, более точно проверять зависимость.