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)

Ответ на: комментарий от CrossFire

Сейчас мало кто заказывает десктопные приложения без кастомного дизайна

Под винду? Ибо у меня строго противоположная статистика.

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

Тьяго вообще там много глупослей понаписывал в требованиях.

Тиаго тот еще подсадной казачЁк.

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

А смысл? У него был шанс взлететь, если бы он был по умолчанию в QtC.

Как альтернатива наркоманскому синтаксису CMake: Qt переходит с qmake на CMake (комментарий)

Правда я должен покаятся сразу: я Qbs не пробовал, только хотел потыкать, да руки не доходили.

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

наркоманскому синтаксису CMake

Синтаксис у него, конечно, весьма своеобразный, но настоящая наркомания - это autotools. После него, CMake с ОДНИМ файлом конфигурации с одним единообразным синтаксисом смотрится как манна небесная.

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

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

Всегда такое было.

Сколько не говори «халва», во рту слаще не станет (-:

Вот сделал тривиальный проект, продемонстрировать насколько сломан qmake: https://bitbucket.org/dendyua/qmake-broken-dependencies

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

Ubuntu 18.04 В репах убунты он старый. Темболее (уже) несвежий LTS.

Даже если сейчас всё нормально вот сделали вчера.

Как это отменяет безобразие такого, которое было больше шести лет?

Тут вот нетбинс слегка медным тазом накрылся. И вот я решил первый раз потыкать Qt Creator как типа IDE для C++

Я работал в разное время Eclipse, Netbeans, Visual Studio, RAD Studio, Xcode...

Ну вот только про QtCreator+Cmake могу только матом описать. Охота взять и ну его на это закрыть...

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

Makefile тут ни причём. Просто делай шаги последовательно. qmake вызывается только на этапе step1, на остальных просто: make && ./run.

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

Это гораздо лучше, чем терпеть, когда cmake на каждый чих заставляет пересобирать все исходники. Только на ccache и спасает

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

А, я собрал мастер сначала.

Документ не читай, сразу запускай (-: Там последовательно переключаешься по тегам, иммитируя правку кода. И вызываешь make && ./run, чтобы собрать и проверить.

добавляешь новые зависимости - вызываешь qmake

Во-первых, новые зависимости не добавлялись. Во вторых, ты только что подтвердил, что в самом qmake зависимости не отслеживаются. Любая правка — переконфигурируй проект вручную. Ну и в-третьих, я сейчас могу дописать этот пример, там где даже переконфигурирование не спасёт, только полная чистка.

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

cmake на каждый чих заставляет пересобирать все исходники

CMake можно много в чём винить, но только не в обработке зависимостей. Он корректно пересобирает ровно те файлы до единого, что необходимо, и ни файлом больше.

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

Во-первых, новые зависимости не добавлялись

Ну как это, foo.h стал зависеть от bar.h

Ну и в-третьих, я сейчас могу дописать этот пример, там где даже переконфигурирование не спасёт, только полная чистка.

ИМХО, лучше почистить, когда что-то поломалось, чем делать это без согласия пользователя

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

То чувство, когда ты успел сказать «упс», а эта гадина уже стерла несколько гигабайт объектников

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

Код не запускал. Но я не раз делал рефакторинг в своих проектах и ничего не ломалось.

Святая наивность. Я уже и код предоставил, а в ответ: «Вы всё врёти!» (-: В мало-мальских проектах на qmake из пары десятков файлов сломанные сборки выстреливают на регулярной основе.

Dendy ★★★★★
() автор топика

Ну может и к лучшему. CMake не идеален, но зато будет в большинстве проектов.

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

Ну как это, foo.h стал зависеть от bar.h

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

лучше почистить, когда что-то поломалось

То-есть ты подтверждаешь, что в qmake это нормально, когда что-то там фиг-его-знает-что сломалось и ты руками чистишь и строишь всё заново?

То чувство, когда ты успел сказать «упс», а эта гадина уже стерла несколько гигабайт объектников

Если стёрла, значит это было необходимо. Или поменялись системные заголовочники. Или кто-то добавил какой-то warning или define. Или ещё какиа инклуды потрогались/подвигались как результат ребейза в гите. CMake ни единого файла не стирает и не пересобирает просто так. И пересобирает ровно сколько нужно. Я на протяжении месяцев работаю с проектами по несколько тысяч файлов, которые правятся с сумашедшей активностью, при этом ровно одной командой make/ninja CMake делает 100% рабочие сборки.

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

Если стёрла, значит это было необходимо

Мб, но мне бы хватило пересборки нескольких файлов

Или поменялись системные заголовочники

А вот это не отслеживается как раз

Или ещё какиа инклуды потрогались/подвигались как результат ребейза в гите.

Ну вот они потрогались и все, абзац

annulen ★★★★★
()

мне, честно говоря, фиолетово. главное, чтобы оно дурацкий креатор не требовало и собиралось стандартными тулзами, которые обычно есть в системе, а не какими-то странными велосипедами, которые непонятно как править и настаивать в случае, если ты вносишь локальные изменения в сборку. в этом плане cmake, конено, не самый лучший велосипед, но, по крайней мере, документированный и давно известный. лучше, чем какой-то частный и уникальный.

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

А то прям жесть с cmake в QtCreator

УМВ отлично Р, ЧЯДНТ? (По ссылке не ходил, т.к. не интересно, поскольку УМВ отлично Р.)

А новость хорошая: вовремя или нет, но поняли, что стюардессу пора закапывать. Не помню уже, в какие проблемы с qmake я вляпывался, но переход с него на cmake был вынужденный. Вот бы ещё потом и cmake закопали в пользу какого-нибудь build2 или чего аналогичного — с поддержкой идеи репозитариев.

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

Как это отменяет безобразие такого, которое было больше шести лет?

Конечно да, но ведь пофиксили и работают над улучшением. Последним временем вообще много вкусностей.

тем не менее

  • нельзя license template per project
  • header-guard через
    #ifndef FILE_H
    #define FILE_H
    ...
    #endif
    
    ни шаблона не сменишь, ни тебе #pragma once (в курсе, что нестандарт, но все компиляторы умеют)
  • Когда создаешь класс в .cpp файле #include "Header.h" хотя я предпочитаю полный путь от корня проекта (т.е. #include "stuff/otherstuff/Header.h")

Но все это мелкие недочеты и они не мешают Qt Creator быть одним из лучших (если не лучшим) IDE для крестов.

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

Но все это мелкие недочеты и они не мешают Qt Creator быть одним из лучших (если не лучшим) IDE для крестов.

+1. Лучший из худших. :) По-настоящему классных IDE, таких как IDEA для жавы, для плюсов увы даже близко нет. Но кстати, в бете qt-creator 8.2 впервые заюзали language server protocol. Я аж прям вся дрожу-теку от предвкушения. В блоге ихнем было правда сказано применительно к питону, поэтому боюсь как бы не обломаться с плюсами...

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

Или ещё какиа инклуды потрогались/подвигались как результат ребейза в гите.

Ну вот они потрогались и все, абзац

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

Если ты в гите решил поправить сообщение коммита где-то там вниз по дереву истории или ещё с какой целью необходим ребейз без трогания всего подряд — то для вас изобрели git worktree, советую почитать. Если коротко — ребейзишь историю в отдельной директории, а в целевой просто делаешь checkout на результат.

Dendy ★★★★★
() автор топика

«И увидел, что это хорошо.»
CMake хорошЪ, даже не смотря на, скажем так, не идеальный синтаксис.

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

Да я пользуюсь, иначе вообще одни пересборки были бы

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

Creator просто чудовищен. Kdevelop, даже VSCode на порядки лучше. Всё прибито ржавыми гвоздями. Ужасно :(

Девалопить «под Qt» на нем наверное неплохо, всё остальное - срамота.

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

Хорошая...

А вот это, на мой взгляд, следствие принципиальной особенности cmake — это всего лишь скриптовый язык с батарейками для построения сборочной системы из коробки. Поэтому далеко не ясно, куда там что добавлять, особенно если CMakeFile был затянут «со стороны». (Это всего лишь моя гипотеза, могу ошибаться.)

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

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

Начинал я с qt, просто для раскачки, а щас на голых плюсах пишу. KDevelop помнится с полгода назад поставил-запустил, но чёт не зашло, потом решил погуглить что народ пишет, и таки-ругают его больше и чаще, чем creator. Никаких подробностей не помню, но в итоге решил остаться на creator.

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

А вообще есть потрясающий блог про qmake: http://blog.mgsxx.com/?page_id=1294

Открыл сие творение на свою голову...

Хрен поймешь, что это такое и нафик оно нужно. Как я выяснил, это еще и не совсем верная и изрядно устаревшая информация.

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

В Qt 5 эта настройка включена по умолчанию. Мазохисты могут ее отключить (CONFIG -= depend_includepath), но я не советую. Жизнь слишком коротка, чтобы тратить ее на всякие глупости.

Анонимус, ты сделал мой день (-: P.S. Эта опция не помогает, почему — объяснил в README.

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

и за 18 (или сколько там) лет туда так и не завезли зависимости между заголовочниками

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

а спонтанные make clean на любой чих становятся привычным делом

А тут, на мой взгляд, виновата не qmake, а отсутствие в крестах полноценной модульности (хотя бы как в современных диалектах паскаля).

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

Я добавляю в проект всё по wildcard-у:

file(GLOB_RECURSE FILES include/*.h src/*.h src/*.hpp src/*.cpp)
add_library(${NAME} STATIC ${FILES})

(Можно ещё короче, не перечисляя подкаталоги и расширения.) И плевать что это типа не рекомендуется, там аргументация «против» дурацкая какая-то.

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

Там выше по треду я кинул ссылку на проект на bitbucket с примером как сломать зависимости в qmake.

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

Ох уж эта молодёжь. Одни наркоманы и проститутки. Всё бы им сломать.

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

+1. Лучший из худших. :) По-настоящему классных IDE, таких как IDEA для жавы,

Да, надо признать что пинок под задницу C++ IDE начался относительно недавно.

IDEA

Ты поосторожней терминами кидай, ато щас набежат все эти полтора любителя CLion и будут тебе доказывать.

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

Да, надо признать что пинок под задницу C++ IDE начался относительно недавно.

+1. Что внушает надежду на светлое будущее.

Ты поосторожней терминами кидай, ато щас набежат все эти полтора любителя CLion и будут тебе доказывать.

CLion чудовищно тормозит даже на «hello world» в 10 строк, и у него дикие глюки с синтаксическим анализом. Я хз как JetBrains ухитрились сделать такое говно, и хз как не постыдились его продавать. Обидно, в общем: все ихние прекрасности, общие для всех ихних IDE, там присутствуют, ещё б оно работало...

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

Проблемы с зависимостями в qmake есть. Но думаю, это решаемо патчами,

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

А тут, на мой взгляд, виновата не qmake

Я знаю! Виноват, не qmake. А его автор. И мейкфайлы. И всемирное потепление. И цены на бензин.

QMake — вполне себе конкретный проект и причина сломанных зависимостей там на виду. Сотни сторонних проектов на тех же мейкфайлах поняли, что зависимости нужно отслеживать пофайлово и даже сохранять в отдельный файл для каждой единицы трансляции (.d). Более того, даже опции компилятора принято хранить в отдельный файлах, или генерировать на лету. QMake просто игнорирует все эти подходы и выдаёт ровно один Makefile, который работает исключительно в варианте неинкрементальная сборка с нуля. Это не чинится.

Меня всегда изумлял подход: сделать криво, зато коротко. Написать нечитаемую белиберду кода, зато в одну строку.

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

Как будет время попробую shakebuild.com как систему сборки. Внешние зависимости правда придется pkg-configом прикручивать, хотя можно организовать сборку сразу через nix (интересно можно ли у него спросить флаги линковки к либе как у pkg-configа)

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

В мало-мальских проектах на qmake из пары десятков файлов сломанные сборки выстреливают на регулярной основе.

4.2

Я qmake использую на постоянной основе. В текущем проекте 484 файла. УМВР.

Единственный баг, это кривое обновление moc_* файлов при удалении/добавлении макроса Q_OBJECT. Но я хз кто в этом виноват.

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

А вообще есть потрясающий блог про qmake

Спасибо, схоронил.

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

И здесь у меня вопрос: ты правда после каждой правки #include в коде переконфигурируешь проект вручную?

QtC делает автоматом.

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

Виноват, не qmake. А его автор.

Именно так. :) В основе qmake лежали неплохие идеи (даже сейчас файл проекта, который должен уметь собираться и с Qt4, и c Qt5, выглядит на qmake куда лучше, чем на cmake), но авторы не решили некоторые проблемы и кое-где накосячили с реализацией. Одно то, что фигурные скобки для условных блоков надо писать строго по шаблону, вымораживает...

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.