Ну тут очень поверхностный ответ: нужен кросстулчейн, и rootfs той платформы для которой происходит сборка.

В rootfs должны быть не только .h файлы для соответсвующих либ, но и pkgconfig/*.pc файлы зависимостей. Плюс для configure должен быть соответсвующий файл

Вот к примеру сниппет для сборки

export SDK_DIR=/myplatform/sdk
export TOOLCHAIN_SYSROOT=$SDK_DIR/output/socplatform/host/arm-linux-gnueabihf/sysroot
export PATH=$PATH:$SDK_DIR/output/socplatform/host/bin
export PKG_CONFIG_LIBDIR=$TOOLCHAIN_SYSROOT/usr/lib/pkgconfig
export PKG_CONFIG_PATH=$(PKG_CONFIG_LIBDIR)
export PREFIX=$SDK_DIR/output/socplatform/qt-5.8.0


mkdir $SDK_DIR/output/socplatform/qt-5.8.0/ext
mkdir $SDK_DIR/output/socplatform/qt-5.8.0/host


./configure  -v -extprefix $PREFIX/ext -hostprefix $PREFIX/host \
    -release -opensource -confirm-license -qpa eglfs -qt-pcre -fontconfig -pkg-config -no-pch -no-xcb -no-dbus -no-iconv -no-cups -no-gtk -system-zlib >
    -no-rpath -make libs -nomake tests -nomake examples -no-warnings-are-errors -no-qml-debug \
    -D EGL_FBDEV -eglfs -opengl es2 -recheck-all \
    -platform linux-g++-64 -device linux-arm-myplatformhf -device-option CROSS_COMPILE=arm-linux-gnueabihf-  -device-option TOOLCHAIN_SYSROOT="$TOOLCHAIN_>
    -skip qt3d -skip qtactiveqt -skip qtandroidextras -skip qtcanvas3d -skip qtcharts -skip qtconnectivity -skip qtdatavis3d -skip qtdoc -skip qtgamepa>
    -skip qtlocation -skip qtmacextras -skip qtmultimedia -skip qtnetworkauth -skip qtpurchasing -skip qtquickcontrols2 -skip qtscript -skip qtscxml -s>
    -skip qtserialbus -skip qtserialport -skip qtspeech -skip qtsvg -skip qttools -skip qttranslations -skip qtvirtualkeyboard -skip qtwayland -skip qt>
    -skip qtquickcontrols  -skip webengine -skip qtdeclarative -skip qtwebchannel -skip qtwebsockets

Использование GPU для eglfs бэкэнда контролируется во время сборки Qt, через configure

./configure… -eglfs -opengl es2…

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

Но надо понимать что для eglfs ускорение используется очень ограниченно. Большинство графических примитивов отрисовываются в software режиме, но на EGL плоскости. И ускорение в основном касается блитта и копирования части графической поверхности.

eglfs(fs — full screen) — в этом режиме работы бэкэнд отрисовки Qt рисует прямиком во framebuffer. Родительский виджет (root) занимает всю видимую область экрана.
Концептуально отличается от linuxfb тем что имеется минимальное аппаратное ускорение
при блитте поверхностей.

Таким образом сначала надо сконфигруировать framebuffer, а затем через переменную окружения указать активный «qpa»

Информации на самом деле достаточно. К примеру вот здесь неплохо описано:

doc.qt.io/qt-5/embedded-linux.html

Немножко в теме: все эти медиацентры малоэффективны до тех пор пока нет поддержки аппаратного декодирования видео. Большинство приставок на software decoder'e не вывезут даже h.264 в FullHD, не говоря уже о 4k hevc/h.265.
К примеру тут упоминали X96 max+: на Android все это есть (аппаратное ускорение) для AMLogic S905x3 чипа. Есть сборки Armbian для этой приставки, но туда еще не завезли ускорение на уровне драйверов.
PS: Кстати на Android X96 max+ есть изкоробки KODI mediacenter. Лично мне нравятся приставки Infomir.

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

Чисто субьективно: IntelliSense плачет, я плачу, люди которые читаю код после меня тоже страдают — зачем это все? Чтобы «красиво» написать все в 2 строки, а не в 4 понятно?

По правде говоря думая о Ragel я представлял в уме BNF, нежели стандартные регулярки. Не могу понять пока уместно ли говорить о DFA/NFA в контексте Ragel. Задумался, пошел читать Википедию.

Для своих нужд использовал Ragel. +100500 к гибкости, и по скорости также отлично.

Возможно Вы промахнулись с эпохой? может зумеры?

Отличная статья, отличные слайды и отличное чувство юмора (нам нравится одна и таже шутка) — спасибо! Таки да статью не читал, но о̶с̶у̶ж̶д̶а̶ю̶ одобряю!

Старая шутка: если у Вас есть проблема и Вы хотите решить ее при помощи регулярных выражений, то у Вас уже две проблемы.

Как-то сложно, уж проще svg с QR кодом встроить через <svg/> в тело html.
Во времена FIDO была шутка с передачей информации через wav файлы, в которых ты через микрофон надиктовывал UUENCODE полезной нагрузки.

Так я ведь и написал что время от времени мониторю свежие версии — именно на основании этих наблюдений и делаю вывод что С++Builder застрял в прошлом веке.
Пользовался плотно — критерии сравнения вполне осознаны.

С++Builder 6 это не первая версия которой я пользовался — и если до нынешних дней
дошли «родовые дефекты» из первых верий, то считаю такое надо отпустить (и забыть). Само собой это мое частное мнение, и именно так я и поступил в свое время.

«На сдачу» — очень метко. Последняя боевая версия С++ Builder, которой я пользовался, это была 6.0. Причем я использовал какой-то дико популярный в то время VCL компонент для отображения таблиц(не помню как назывался), и проект не собирался в таком случае если не пропатчить среду до «Hotfix update 4». Про Boost уже говорили…
А последнее что я запомнил о Delphi это проблемы с unicode, но кажись уже все хорошо. Хорошо?
PS: свежие версии C++Builder ставлю примерно раз в год, ради забавы. Ностальгия, так сказать.

У меня есть опыт сборки Qt 5.8 при помощи distcc(без ccache) на Ryzen 7 3700x (8 ядер, 16 потоков) на 16GB RAM, 100 Mbit/s LAN. И по правде говоря выигрыш в сборке в пределах 10%-20%. Основные затыки были на линковке, которая не параллелится.

Боюсь что накладные расходы на дистрибуцию задач по нодам Incredibuild/distcc больше чем затраты на локальную сборку. Особенно на таком монстре как Threadripper 3990X.

Хотя допускаю что сильно зависит от проекта который собираешь.

Продукт (C++ Builder) был неплох лет 20 назад. Но складывается впечатление что он не развивается и так и застрял там.
С Delphi подозреваю дела чуть получше. Не вижу смысла сейчас использовать «это» — уж проще тогда Qt + QtCreator или C#+WinForms.

Ну на видео видно что палец выпрямлен, а на загнут как бывает когда работает с тачпадом. Я попробовал манипулировать пальцем таким образом, и у меня сразу начало ныть в запястье. По ощущениям примерно также как будто-то бы рука на весу.
Это у меня так только ?!

Не хочу обесценить труд автора, но пробовали ли вы когда-то вешать занавески/шторы на каринизе? Уже через пару минут «рук на весу» они становятся ватными, и их хочется опустить. Точно также и с этими интерфейсами — это круто и зрелищно, но не практично. Даже XBox/Kinect страдает этой осбенностью.
В качесте proof-of-concept очень круто. Можно потом применять в более подходящих целях.

В мае была новость что Zoom приобрел Keybase. Надеюсь что они возьмут на вооружение лучшие решения.

По правде говоря даже С++11 временами поддерживается с горем пополам, имеющимися тулчейнами. Бывало такое что вообще фичи были в пространстве имен std::tr1. Так что С++20 для многих это фантазии, к сожалению.

Прошло много лет, а в голове все застряло — «ехал Ларри на машине, весь размазанный по шине» :-\