LINUX.ORG.RU

Qt переходит с qmake на CMake

 , , ,


4

4

Сегодня в официальной рассылке Ларс Кнолл (Lars Knoll) подтвердил давно ходящие слухи об отказе от qmake в пользу CMake начиная с Qt 6.

Данное решение было результатом многочисленных дискуссий по поводу будущего системы сборки Qt. Команда признаёт, что эволюция qmake зашла в тупик и замена его было лишь вопросом времени. В июле Тьяго Мацейра (Thiago Macieira) перечислил требования к будущей системе сборки, из потенциальных кандидатов, удовлетворяющих им, в итоге остались Qbs и CMake.

Qbs разрабатывался внутри The Qt Company как альтернативная система сборки общего назначения, призванная избавиться от болячек qmake и предложить разработчикам декларативный язык описания проекта на основе QML. К сожалению, проект так и не получил достаточного развития и в последнее время поддерживался усилиями буквально одного человека. Для того чтобы Qbs конкурировал на рынке необходимо было бы приложить усилия, несоизмеримые с текущими возможностями и бизнес-целями компании. Таким образом, единственной областью применимой для Qbs мог бы стать перевод на неё самой Qt. Но даже это оказалось трудновыполнимой задачей из-за циклических зависимостей между Qt и Qbs, что прямо противоречило одному из основных требований.

И Qbs, и CMake показали хорошие результаты в ходе эксперимента по сборке Qt, но разработчики отмечают насколько далеко они сумели продвинуться именно с CMake за короткий промежуток времени.

Среди прочих достоинств CMake упоминаются широкое расспространение в экосистеме C++, в частности KDE, хорошая поддержка в популярных IDE и пакетных менеджерах (VCPkg, Conan и прочие), а также большая база пользователей.

Модули CMake уже официально входят в состав Qt 5 и планировались поддерживаться и далее наряду с qmake. Добавление третей системы сборки стало бы слишком тяжёлой задачей, поэтому отказ от Qbs был во многом предопределён.

Компания уверена в своём выборе CMake для Qt 6. Результаты уже сейчас можно опробовать в проекте qtbase, переключившись на ветку wip/cmake. Желающие принять участие в портировании остальных модулей приглашаются к сотрудничеству.

В дополнение, в официальном блоге Qt сегодня также заявили про прекращение разработки Qbs: http://blog.qt.io/blog/2018/10/29/deprecation-of-qbs.

>>> Подробности

★★★★★

Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 13)
Ответ на: комментарий от Dendy

Проблема не в том, что qmake не делает зависимостей от инклудов, он их делает как надо, а в том, что он не делает зависимости Makefile от всех исходников.

На третьем шаге у тебя появилась зависимость foo.h от bar.h, поэтому должен быть запущен qmake кем-то.

Вариантов тут два: либо ты руками запускаешь qmake после апдейта из репа или когда сам понаписал такое, что приводит к новым зависимостям. Второй вариант - это всегда запускать qmake (или иной генератор Makefile) перед сборкой.

Решения для второго варианта описано здесь: http://blog.mgsxx.com/?p=2166

cmake всегда проверяет зависимости перед сборкой или вручную нужно его запускать?

anonymous
()
Ответ на: комментарий от anonymous

cmake всегда проверяет зависимости перед сборкой или вручную нужно его запускать?

Если у меня в CMakeLists.txt файлы проекта заданы не поимённо, а wildcard-ом, то после добавления нового файла я делаю touch CMakeLists.txt (это быстрее чем добавлять новый файл туда ручками, у меня скрипт на шоткате). При изменении уже существующих файлов cmake распознаёт изменения.

dimgel ★★★★★
()
Ответ на: комментарий от anonymous

У CMake генерация зависимостей вынесена на этап самой сборки, после этапа конфигурации. То-есть при вызове cmake зависимости C++ ещё не собраны. Они будут самостоятельно обновляться в фоне и никогда не бывают сломаны. Переконфигурация также вызывается самостоятельно и только в случае, когда сами скрипты были потроганы, но не C++ код.

Кроме того, в отличии от вышеописанной проблемы с Makefile, который не хранит историю, CMake таки её хранит и знает с какими параметрами был собран каждый объектник, и если они изменились — он будет пересобран. То-есть проблемы с добавлением define'ов нет. К примеру, в случае с Ninja эти параметры хранятся в файле .ninja_deps и обновляются на лету. С Makefile всё немного замороченей, поскольку из коробки в нём такого нет, то CMake сам сохраняет параметры сборки в отдельный файл.

Мораль — нужно генерировать столько промежуточных файлов, сколько нужно. QMake с его идеологией «сломанный Makefile, зато всего один» — сам себе вырыл могилку.

Dendy ★★★★★
() автор топика
Последнее исправление: Dendy (всего исправлений: 1)
Ответ на: комментарий от dimgel

я делаю touch CMakeLists.txt (это быстрее чем добавлять новый файл туда ручками, у меня скрипт на шоткате)

...тем временем в нормальных языках..

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Сорри, но не верю. Не изучал и пока что не собираюсь, а не верю из общефилософских соображений.

У плюсов философия и языка, и его развития вполне логичная в рамках базовых принципов, озвученных Страуструпом: «не платишь за то что не используешь», «отсутствие необходимости в более низкоуровневом языке для системного программирования», третий не помню. Если эту идею почувствовать, и учесть накладываемые устаревшим синтаксисом ограничения, то всё начинает выглядеть вполне логично и предсказуемо.

Я к тому, что ни раст, ни кто-либо ещё в принципе не могут быть лучше сразу по всем фронтам: у них неизбежно будут свои собственные ограничения. Отличающиеся от плюсовых, обусловленные их собственными базовыми принципами (ежели таковые существуют; если нет, то этот язык будет хуже по всем фронтам, зато как обычно завоюет бешеную популярность).

Так что размен плюсов на раст или что-либо другое — это размен шила на мыло. А точнее, на кота в мешке, который пока ещё неизвестно выстрелит ли.

dimgel ★★★★★
()
Ответ на: комментарий от dimgel

Я к тому, что ни раст, ни кто-либо ещё в принципе не могут быть лучше сразу по всем фронтам: у них неизбежно будут свои собственные ограничения.

Ему достаточно быть лучше. А это не так сложно. И ему это удалось. Достаточно взять cargo, модули, unsafe, std и ADT.

Понятное дело, что он ещё сырой, но даже в таком виде он далеко впереди.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Скала много лет была далеко впереди жавы. На несколько голов выше. И только совсем недавно вошла в 20-ку самых популярных языков. Непонятно кстати, как она туда попала, если в жаву проникает и ФП, и вывод типов, и даже метапрограммирование (lombok). Хотя по компактности синтаксиса и мощности жава всё равно в глубокой жопе; да и lombok надо клонировать чтобы свои макросы писать.

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

Расскажи кстати плиз, в чём по твоим понятиям заключается сырость раста. Т.е. на что обращать внимание в будущих новостях по нему. Я только помню что там были проблемы с параллелизацией сборки, на генте у меня и раст, и firefox в одно ядро собирались.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 2)
Ответ на: комментарий от dimgel

проблемы с параллелизацией сборки

Не слышал. У меня все ядра использует. Возможно приколы сборки самого FF.

в чём по твоим понятиям заключается сырость раста

Именно в сырости.

  • Экосистема молодая (но уже в 100500 раз лучше C/C++, ибо нормальная std и cargo). Действительно хороших либ маловато.
  • Модули к Rust 2018 собираются сильно перекроить. В лучшую сторону, но всё равно.
  • Неясности с обработкой ошибок. Опять же, лучше чем в плюсах, но консенсуса пока нет. Чего только стоит то, что trait Error в std частично помечен как deprecated.
  • async/nll/bench/rustc-test до сих пор unstable.
  • Нема GUI. Это самая большая боль. Хотя его ни для какого языка нет, не считая JS.

С другой стороны, я за два года использования ни разу не нарвался на баг компилятора/std. Правда я пишу код для людей, а не извращения.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Императивная билд-система на самом языке. Хорошо.

За консультацию спасибо.

Про параллельность сборки — обсуждалось на ЛОРе раньше, кто-то отписывался, что над этим работают, и упоминал про блокирующие эту фичу проблемы, суть которых я не запомнил.

dimgel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.