SCons или CMake вместо qmake [закрыто]

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

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

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

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

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

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

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

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

Ура, f.

10
cmake qmake scons

1 ответов

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

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

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

CMake

плюсы:

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

плюсы:

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

проектов SCons

плюсы:

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

плюсы:

  • SCons может не так широко использоваться, как CMake, но по-прежнему имеется много поддержки.
  • в зависимости от размера проекта, SCons может использовать много памяти, так как он анализирует все сценарии сборки и строит дерево зависимостей в памяти перед компиляцией. Однако это позволяет проводить более точную проверку зависимостей.
7