https://www.opennet.ru/opennews/art.shtml?num=57847 #ball_lick

Тут вот пишут, что вышла новая версия #qt, и я хочу сказать, что сборка QT, после ее перехода на cmake - это леденящий душу пиздец.

Связано это с:

* #cmake сам по себе говно, в нем нет кросс-компиляции. А в QT есть, поэтому им пришлось написать соответствующий слой поверх cmake самим. #cross

* QT решили задачу по переходу, в том числе, оттранслировав большое число проектных файлов автоматом. Для этого им пришлось наговнякать большой runtime поверх макросов cmake, который имплементировал нужную им модель, в которую они и погрузили свои сборочные файлы. https://github.com/qt/qtwayland/blob/dev/src/qtwaylandscanner/CMakeLists.txt#L4

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

К чему этот rant?

https://github.com/pg83/ix/blob/main/pkgs/die/c/qt.sh#L16 - мне пришлось добавить пятый флажок в набор флажков, отвечающих за то, что нужно собрать тулзы, и, желательно, только их.

Реально, там полный набор - от "ну пожалуйста", до "мамой клянусь, они мне точно нужны".

А еще они зачем-то добавили факт о том, что пакет собран кросс-компиляцией, в метаинформацию этого пакета. https://github.com/pg83/ix/blob/main/pkgs/lib/qt/6/base/ix.sh#L45 (я ее вырезал, конечно)

Это вообще какая-то дичь, которую я для себя никак не могу объяснить:

* Их сборка начала ломаться, если этот флаг разный у разных пакетов. Схера ли? build tools могут быть собраны в режиме host == target, а либы - уже в режиме кросс-компиляции, это вполне валидный сценарий.

* А как же воспроизводимость? Пакет должен быть идентичный, неважно, в каком окружении он собран. А тут налицо факт, что пакеты, собранные кросс-компиляцией, будут отличаться.

Будни #bootstrap, #bootstrap_science

Вчера я рассказал про сборку #qt, конкретно, про:

* набор (неортогональных) флагов, которые чуть по разному решают в qt задачу принудительной сборки бинарников в host-target режиме

* про то, что они написали поверх #cmake свой слой кросс-компиляции

* про то, что их система сборки сравнима с "Войной и Миром" Толстого(как по актуальному размеру, так и по уровню графомании)

Сегодня про то, как оно сломалось при обновлении до qt 6.4, и как я "ловко" и "изящно" это обошел.

Есть такой проект - https://github.com/qt/qtdeclarative, и он жестко отказался собираться после обновления. С ошибками конфигурации где-то в недрах своих cmake хелперов, без внятной диагностики(это, кстати, отдельная боль в cmake).

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

С симптомом круговой зависимости, что, мол, какой-то файл зависит от цели, которой нужен какой-то собранный бинарник(с говорящим названием qmltoolregistrar), который зависит от этого же файла. Скажем, вот тут - https://github.com/qt/qtdeclarative/blob/dev/src/qml/Qt6QmlMacros.cmake#L2494

Я копался в этом часа 3, но починить так и не смог, из-за размеров этой махины.

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

Как это было сделано?

* Удаляем из сборочных файлов круговую зависимость. https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L13 После этого получается битый makefile, но его достаточно, чтобы осуществить первые этапы сборки.

* https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L4 - собираем все, что собирается этим битым makefile, и устанавливаем в качестве сборочного результата

* Повторяем эти шаги, постепенно увеличивая число собирающихся таргетов, и используя предыдущие результаты как host тулзы - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/2/ix.sh#L14

Мне понадобилось 2 шага - https://github.com/pg83/ix/tree/main/pkgs/bld/qt/6/tools/qml, результат второго шага вполне достаточен, чтобы им собрать полноценный пакет - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/ix.sh#L12.

Я не рассказал про всякие мелочи, типа ручного релоцирования из build в output директории получившихся cmake файлов, чтобы дальнейшие шаги сборки могли их подхватить - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L21

Звучит это все довольно страшно, но сборку эти 2 дополнительные стадии почти не замедлили, потому что в них собирается процентов 5 от всего набора исходников этого пакета.

Oops!…I Did It Again

У меня тут, при переходе на #QT 6.4, каким-то очень странным образом начала коркаться телега, при попытке отобразить какие-то очень специфические картинки:

[Switching to LWP 14132]
0x0000000009f795b7 in QRgba64 const* fetchTransformedBilinear64<(TextureBlendType)4>(QRgba64*, Operator const*, QSpanData const*, int, int, int) ()
(gdb) bt
#0 0x0000000009f795b7 in QRgba64 const* fetchTransformedBilinear64<(TextureBlendType)4>(QRgba64*, Operator const*, QSpanData const*, int, int, int) ()
#1 0x0000000009f87338 in handleSpans<BlendSrcGenericRGB64>(int, QT_FT_Span_ const*, QSpanData const*, Operator const&)::{lambda(int, int)#1}::operator()(int, int) const ()
#2 0x0000000009f87444 in void std::__1::__function::__policy_invoker<void ()>::__call_impl<std::__1::__function::__default_alloc_func<handleSpans<BlendSrcGenericRGB64>(int, QT_FT_Span_ const*, QSpanData const*, Operator const&)::{lambda()#1}, void ()> >(std::__1::__function::__policy_storage const*)
()
#3 0x000000000a4ce3a1 in QThreadPoolThread::run() ()
#4 0x000000000a4cbdb9 in QThreadPrivate::start(void*) ()
#5 0x000000000a746a6c in start ()
#6 0x0000000000000000 in ?? ()

Проблема в том, что в дебажной сборке нихрена не видно - не падает, а как(и куда) нести такое - непонятно.

Поэтому базовую библиотеку qt я(временно!) собираю без оптимизаций - https://github.com/pg83/ix/blob/main/pkgs/lib/qt/6/base/ix.sh#L61, так оно делает вид, что работает.

Это уже вторая такая библиотека, первой была openssl - https://github.com/pg83/ix/blob/main/pkgs/lib/openssl/t/ix.sh#L25

Морали в этом особой нет, просто "и вот такие решения приходится принимать". На поиск таких ошибок можно полжизни положить, было бы желание.

Я несколько раз писал, что в #cmake нет кросс-компиляции.

До недавнего времени я знал одно исключение из этого правила - это сборочные файлы #qt, они там, по сути, написали на cmake самопальный слой кросс-компиляции, благо cmake turing complete, и грубой силой там можно написать все, что угодно.

Вот, коллеги показали второе исключение из этого правила - https://github.com/ClickHouse/ClickHouse/blob/master/contrib/protobuf-cmake/CMakeLists.txt#L252

Тут "очень изящно" вызывается рекурсивный cmake + make на прикопанную папочку с protoc во время configure этапа. И, к моменту поиска protoc в системе, он уже готов.

У меня, конечно, двойственное к этому отношение.

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

С другой, понятно, что дистростроители с такого вешаются, когда нужно сделать де-#vendor.

С точки зрения upstream, конечно, сборки от дистрибутивов, после ручного де-#vendor, не являются воспроизводимыми, и, наверняка, их не поддерживают (по вполне понятным причинам).

https://www.phoronix.com/news/Qt-6.5-LTS-Released

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

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

"With Qt 6.5's multimedia support the FFmpeg back-end is now the default for macOS / Windows / Android / desktop Linux while for embedded systems GStreamer is the default"

Теперь, по умолчанию, для проигрывания видосов используется ffmpeg, и это очень, очень хорошо. Чем быстрее помрет фабрика по загрузке .so с диска под названием #gstreamer, тем лучше.

Но, на самом деле, мой глаз зацепился за фразу "The Qt 6.5 toolkit brings improved theme and styling support, including better support around dark mode handling on Windows", и я вспомнил, что уже какое-то время хочу рассказать, что, наконец, понял, почему авторы #gtk/#gnome так хейтят сторонние темы!

Считайте меня слоупоком, но я это понял совсем недавно.

В #gtk виджеты не совсем виджеты, а, по сути, настройки для канвы.

Все очень и очень похоже на html + css, берешь любой div, приделываешь к нему рамки из картинок, навешиваешь onClick(), и, пожалуйста, это не div, а уже кнопка.

Поэтому сделать кастомную тему для gtk - это как сделать кастомную css тему для нескольких веб сайтов одновременно. Иногда даже может работать, но, чаще всего, ползет какая-то херня из всех углов!

Что я пока не понимаю - перешли ли разработчики QT на темную сторону со своими qt quick, или еще не перешли.

Пока читал changelog, натолкнулся на https://wayland.app/protocols/cursor-shape-v1 (foot его как раз поддержал).

TL;DR - в #wayland теперь можно сказать композитору, какой курсор сейчас отображать по порядковому номеру (значения которых заранее определены и известны), а не загружая кастомную текстуру каждый раз, когда мышка переезжает из окна с #gtk в окно с #QT. Курсоры (при поддержке этого протокола) теперь могут храниться в композиторе, и не загружаться каждым клиентом отдельно.

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

UPD: "Copyright 2018 The Chromium Authors Copyright 2023 Simon Ser" - ну, понятно, все #хорошее для Linux Desktop делает гагл, а не какой-то там RH.

Интересно, поддержит ли это #gtk?