Сейчас в моде для GTK использовать Vala

«Стандарт» ничего не решает. А универсальность CMake достигается путём кровесмешения, которое приводит к простыням файлов сборки, я всё же сторонник уменьшения сложности, в CMakeLists.txt порой без слёз не посмотришь. А QMake будучи инструментом именно сборки прекрасно и без лишних сложностей свою задачу выполняет.

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

По поводу сложности, то в сценариях, которые простые и для которых подойдет и qmake, ide вроде clion и так умеют все делать автоматически. Надо свыкнуться, что cmake – тоже яп. В джаве тоже могут быть полотна на мавене и груви. Потому что программы сложные и программы для их сборки и автоматизации – тоже.

Он стандарт де-хайпо, только потому что крупные конторы типо гугла и интела его пиарят на каждом шагу, ну а за ними тянутся и Qt и другие, в OS среде я наблюдаю что этого стандарта нет вижу полно различнейших систем сборки и premake и SCons и вечные Make/Automake, тут зависимость по привязке к самим библиотекам, если Qt пиарит и сам собирается с CMake не стоит ожидать, что разработчики использующие Qt будут использовать что-то другое.

УУУУУУУУУУ «Portal 2», «Counter-Strike: Global Offensive», «War Thunder» ничего себе. Как то раньше мимо него проходил.

К сожалению нет. Покажите мне проект на cmake у которого меньше хотя бы 200 строк.

Ну это очень субъективно, для больших проектов всегда получаются тучные сценарии сборки, особенно если учитывать что cmake пытается одновременно быть и скриптовым языком

GTK, есличо — это аналог кутешных модулей QtGui+QtWidgets.

Все это понимают. А каких модулей не хватает если брать во внимание остальные гномьи библиотеки?

Давайте я просто дам сылку, чем разглагольствовать https://www.jetbrains.com/ru-ru/lp/devecosystem-2019/cpp/ Большие компании, как я понимаю, это делают просто потому что, а не потому что это приносит деньги. Мэйк я скорее отношу к смэйк, ибо второй генерирует первое. И как раз из-за распространенности смэйка разработчики qt стали переходить на него, иначе бы и не почесались, прибив все qt гвоздями к qt tools.

Хэлло ворлд напишется за 2. Вы четко сказали 3 файла, ну вот, они и есть. Благодаря модульности я могу писать какие-нибудь пакеты для ROS, редактируя имеющийся CMakeList без проблем. Еще раз, cmake – яп. Да, он сложнее, но предоставляет большие возможности.

«Вам ложь, наглую ложь или статистику». А если серьёзно то во-первых выборка только по крестам, во-вторых уверен что с зависимостями это не так(они исп другие сист сборки), а в-третьих я же говорю де-хайпо, у меня в вузе был курс интела и они нам пиарили cmake и всех разрабов принуждают использовать его, в четвёртых аудитория опрошенных может быть ооочень предвзятой, заметьте что QMake набрал 10% ghjnbd 33% и 40% у make и CMake, т.е. задумайтесь - один единственный фреймворк тащит всего в четыре раза меньшую аудиторию чем собирательные make и CMake.

Надо свыкнуться, что cmake – тоже яп.

Этим он в частности и плох.

ИМХО, идеальная сборочная система должна быть набором декларативных описаний с контролем ошибок и только для подлинно нетривиальных случаев целесообразно предусмотреть секцию unsafe, куда можно будет запихивать всякую скриптоту.

qmake таковой, к сожалению, не является, но мусора там таки на порядок меньше, чем в cmake.

Мне вот нужно, чтобы один проект собирался на Qt4 и Qt5. qmake этого даже не заметит, а для cmake нужно тащить две совершенно разные стены текста

У меня тоже есть гигантский проект, который собирается для Qt4 и Qt5. Единственная разница в CMake это qt4_wrap_cpp/qt5_wrap_cpp, qt4_wrap_ui/qt5_wrap_ui. Я написал однострочную враппер-функцию, которая вызывает одно либо другое. О каких «совершенно разных стенах текста» речь?

Как вариант, самые увлеченные будут рыться в новых минорных релизах и выискивать, какие из изменений могли бы быть багфиксными

Вот в этом и заключается свинство. Я не могу себе представить схему как они собираются воплощать идею закрытия LTS для открытых проектов не харкнув при этом смачно в лицо разработчикам.

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

QMake очень приятный, единственный косяк…

Главный косяк QMake, что он не умеет в инкрементальную сборку. Это одно ставит на нём крест.

А разве должен ? Его задача по идее соответствующий Makefile делать и всё, дальше если всё было правильно настроено, то make будет проводить правильную инкрементальную сборку

Более того, я не понимаю чего они хотят этим добиться. Чтобы открытые проекты поголовно сидели только на новых версиях?

Да, они так прямо же и сказали в своем обращении.

Люди и дистрибутивы, которым нужна старая версия так и будут на ней сидеть.

И сейчас немало опенсорсных проектов сидят на старых версиях, не хватает рук и мало смысла переползать на свежую минорщину. Вот их хотят *заставить*, вынудить точнее. Ну, как вариант, какая-то сторонняя крупная контора может поддерживать свой независимый LTS-форк, и все будут от туда тянуть заплатки.

Только жизнь усложните и ухудшите к себе отношение.

Их маркетинговый отдел, судя по всему, к этому готов. Хотя, 500-баксовый варик, ящитаю, это хороший мув, хоть и непонятный по лицензированию.

А разве должен ? Его задача по идее соответствующий Makefile делать и всё, дальше если всё было правильно настроено, то make будет проводить правильную инкрементальную сборку

Про это и речь, QMake никогда не генерировал Makefile для инкрементальной сборки, только для холодной сборки с нуля. Такой опции просто не существует и никогда не было ещё с Qt3. Идея сменить систему сборки не от хорошей жизни возникла, в том числе и по этой причине, они её уже лет 10 как мусолят. CMake при всех его недостатках по крайней мере работает.

А зачем он объектники не чистит тогда ? Да и вроде правила в Makefile прописаны под инкрементную, объекты создаются независимо, не очень понимаю, где сборка становится не инкрементальной.

Да и сколько процентов пользователей Qt пользуются этим функционалом?

Эмбеддед для них как раз основной рынок. Ну или по крайней мере они так считают:

QT is focused on phones and touch displays, like in cars. They were at CES in some weird place, a suite on like the 25th floor of the Venetian. There was really no foot traffic because they were so off the beaten path and a number of higher level people were there.

I talked with them for about an hour on their future, focus, and direction. Desktop Linux doesn't make the list. At all. It's not a revenue source.

They want to be b2b for kiosks, cars, and other screen interfaces. They have a direct framebuffer QT and some other optimizations which would be great if Arm chips and RAM weren't cheaper than dirt.

(c) Рассказ посетителя последнего CES

О лицензии и тапочках или лицензия Qt для KDE

https://vk.com/wall-33239_4992 Дисклеймер: смена лицензии Qt для KDE определяется комитетом 4-ёх(2 представителя от тапок, 2 от куты), в случае ничьи решает KDE, а случае полного закрытия исходников, KDE может открыть последнюю свободную версию по BSD.

Да и вроде правила в Makefile прописаны под инкрементную

Я больше скажу, весь Makefile задумывался как инкрементальная сборка, но в абсолютном большинстве случаев он таким не является и QMake не исключение. Один из немногих случаев, в которых инкрементальная сборка действительно работает это Makefile, сгенерированный CMake’ом.

Можешь убедиться в сломанной инкрементальной сборке сам, вот тривиальный тест: https://bitbucket.org/dendyua/qmake-broken-dependencies/src/master/

Соглашусь, но это ведь так только для заголовочных получается и только тех, что не подключены в main.

Соглашусь, но это ведь так только для заголовочных получается и только тех, что не подключены в main.

Сломаны зависимости всех заголовочников, которые включены в другие заголовочники. Что охватывает практически 100% проектов на C/C++.

Тут не поспоришь, косяк, но я придерживаюсь разделения .h/.c(pp), поэтому благо меня эта беда в целом обходит.

Разделение вообще здесь ни причём. Если в один заголовочник включён другой, то при изменении того другого объектник не пересобирается.

Вот другая проблема: добавь в .pro DEFINES += FOO и обнаружь, что ничего не пересобралось. Вопрос на засыпку: почему? И почему аналогичное изменение в CMake таки заставит пересобраться.

Вобщем, всё это приводит к тому, что в более-менее большом проекте переключение между ветками вызывает гарантированные ошибки в проектах на QMake. И хорошо если это ошибка на этапе компиляции или линковки. Фатально когда всё собралось, но половина с одними заголовочниками, половина с другими, половина с одними макросами, половина с другими. И ты сидишь как дурак часами отлаживаешь проблему, которой нет.

Уже на ней. Не понравилось.

Не падает и ладно. И выпадающий терминал из коробки.

This price includes the use of the full Qt for Device Creation product, but not any distribution licenses – these need to be agreed separately.

Они что с каждым стартапом будут отдельно тереть под какой лицензией и что ему можно продавать из своих продуктов, в которых используется Qt? :)

Причём разработчик и издатель вполне могут быть разными лицами. И что там они должны обсуждать с разработчиком – который ничего не знает вообще и скован соглашением о неразглашении. И зачем учётка издателю? Чтобы скачать не упавший ему Qt? Я не понимаю как это должно работать по их мнению.

Для установки бинарных файлов Qt потребуется учетная запись Qt

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

А можешь заплатить 500 баксов и получить LTS-версию, техподдержку и, самое главное, право закрыть свой код.

500 баксов не дают разрешения на распространение.

gui можно разрабатывать в repl интерактивно, не перекомпилируя всю программу. А Qt со своим С++ так могёт? :)

Compiling....
Estimate - 1h

оно выглядит как не пойми что?

и вся аргументация? ИМХО, нормально выглядит

QMake ограничен простыми сборками. А вот что-то нетривиальное на нем уже хрен сделаешь. Вот например из того что я делал:

Это сделал средствами qmake или нет ?

Это сделал средствами qmake или нет ?

CMake разумеется.

создание deb пакета после сборки (также поддерживаются и другие форматы пакетов)

Насколько я помню, это фича cpack, который можно использовать и без cmake.

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

У меня тоже есть гигантский проект, который собирается для Qt4 и Qt5. Единственная разница в CMake это qt4_wrap_cpp/qt5_wrap_cpp, qt4_wrap_ui/qt5_wrap_ui. Я написал однострочную враппер-функцию, которая вызывает одно либо другое.

А на примеры можно поглазеть? Или это закрытый проект?

По поводу остального — процитирую свой комментарий трёхлетней давности:

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

Кажется, что вместо собственного языка cmake-скрипты вполне можно было бы писать на питоне или луа, присобачив к ним соответствующую библиотеку, и получилось бы примерно то же самое. Для элементарных вещей надо писать много буков. Слишком многое завязано на установку переменных, при этом опечатки в именах переменных никто не контролирует. Я сначала было поручил разбираться с cmake своему студенту, потом увидел, что он написал «set(CMAKE_IN_SOURSCE_BUILD TRUE)» (и это прокатило), и сел разбираться сам. Успеет ещё покалечить себе психику другими способами.

CMake разумеется.

ну ок, cmake молодец
но почему это не сделать отдельным скриптом и не привязываться к cmake ?
я бы не стал это делать именно в cmake

это фича cpack

Да но его подключил и дальше работаешь через CMake, т.е. он интегрирован и потом ты просто делаешь make package и готово.

но почему это не сделать отдельным скриптом и не привязываться к cmake ?

Так у CMake это тоже скрипт. А зачем скрипт еще тянуть на другом языке, ведь CMake я и так использую, так почему бы не сделать скрипт на самом CMake?

так почему бы не сделать скрипт на самом CMake?

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

А на примеры можно поглазеть? Или это закрытый проект?

Проект закрыт, но ничего особенного там нет. Конкретно переключение между Qt4 и Qt5 так как я написал. Плюс find_package() соответствующий. Ну и изменения в API самого Qt тоже чинить пришлось в C++, благо они минимальны.

cmake-скрипты вполне можно было бы писать на питоне или луа

Абсолютно согласен. На момент создания CMake свой собственный язык имел смысл, фактически у CMake не было зависимостей, он полностью self contained. Но эта идея давно себя изжила, особенно когда API начало обрастать своим подобием стандартной библиотеки с ужасным синтаксисом, вроде прочитать файл или сложить два числа. А сам CMake без бутстрапа уже давно не собирается. Принцип того что все переменные есть строки, а попытка разименования несуществующей переменной возвращает пустое место это глупость и однозначно в большинстве случаев результат ошибки, а не удобство. CMake погряз в легаси, продолжая поддерживать уже написанные проекты на его языке.

для независимости от cmake

Я и так проект собираю cmake-ом. Ты может еще предложишь вручную Makefile заполнять?

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

Имеет или нет - это слишком субъективно. Так или иначе ЕСТЬ необходимость собирать deb пакет. И удобно, что я это могу сделать с помощью CMake не прибегая к дополнительным инструментам.

кроме простейших случаев

Каких простейших? Создание deb- пакета в принципе не особо сложное занятие, что там может быть сложного, с чем CMake не справится?

лет через 50 мы сделаем очередной круг и вернёмся на нативные библиотеки которые будут уметь всё тоже самое, что умеет браузер

Но нативные библиотеки уже имеют в себе браузер.

Проще выкинуть Qt и софт, который на него завязан. С поддержкой сообщество не справится, так как реально знающих и желающих помочь стремится к 0.

Зачем выкинуть? Проще брать последнюю на момент выхода версию в сорцах и держать её без апдейтов до самого конца LTS.

Ты может еще предложишь вручную Makefile заполнять?

Удобство тебе все делать через cmake не означает убогости qmake по задаче именно сборки, когда она действительно простая

За QMake я и не агитирую.

Этим он в частности и плох.

ИМХО, идеальная сборочная система должна быть набором декларативных описаний с контролем ошибок и только для подлинно нетривиальных случаев целесообразно предусмотреть секцию unsafe, куда можно будет запихивать всякую скриптоту.

qmake таковой, к сожалению, не является, но мусора там таки на порядок меньше, чем в cmake.

Мне нравится подход Rust. Сама сборка описывается декларативно и очень интуитивно. А вот там, где нужно подстраивать что-то нестандартное, то там пишется код на языке Rust в файле build.rs, чья задача выдавать в stdout нестандартные опции компилятора rustc. Красотища, короче!

Это эмбеддед такой мощный или Qt такой быстрый?

Это основная проблема. Остальное уже можно не обсуждать.

Плюс для карго легко пишутся и устанавливаются плагины. Но мы же про болото сейчас. Тут всё по прежнему как 30 лет назад.