LINUX.ORG.RU

Xenolith: Clang в браузере, сборка нативных С++ приложений для Windows, Linux, macOS прямо со страницы

 , , , ,


2

2

Группа энтузиастов собрала SDK, позволяющий собирать полноценные настольные приложения прямо в браузере.

Система устроена так: инструменты сборки разделены на две части: host и target. Часть target полностью независима от платформы, на которой выполняется компиляция, что позволяет использовать её для сборки приложения на любой платформе, включая браузер.

Далее, этими же инструментами собирается сам clang с целью wasm32-unknown-unknown, он и выполняет сборку в браузере.

Для того, чтобы система запускалась. создана «зонтичная» libc, которая транслирует внешние POSIX функции в функции системы. Эта libc одновременно заменяет UCRT на Windows и служит полноценной libc в WebAssembly.

Лицензия запрещает поставлять заголовки Windows SDK и macOS SDK в браузерную систему, потому им найдены замены. На Windows это ручные функциональные замены для функций WinAPI, которые линкуются с системными DLL независимо от Windows SDK. На macOS создан открытый sysroot на базе открытых заголовков XNU и открытых проектов Apple.

Поверх собственной libc собирается llvm libc++, прикладные библиотеки (curl, openssl, freetype, libpng и прочие), собственные прикладные средства и собственный открытый графический движок Xenolith Engine.

Система сама выбирает графический API и API оконной системы, за счёт чего одно и то же приложение может работать на Linux в режимах X11 или Wayland. Поддеживается WebGPU, что позволяет запускать графические приложения там же, в браузере. Инструменты сборки для Linux поставляются со старой glibc (2.33), за счёт чего могут запусаться на современных системах и линковаться с glibc старших версий бесшовно, без контейнера или другой обёртки. Все нужные зависимости собираются статически, либо линкуются динамически через dlopen. На Windows, среда (включая поставляемый бинарно clang) не использует реализаций С и C++ от Microsoft, вместо этого реализована собственная базовая библиотека и подсистема старта.

Система сборки – GNU Make (4.1+), однако для Windows и WebAssembly используется собственный сборщик xlmake (его исходный код также в репозитории), полностью совместимый по синтаксису с GNU Make. Он необходим, поскольку обычные Makefile часто ожидают Linux-подобную среду исполнения, а на Windows и WebAssembly её нет. xlmake подменяет вызовы к стандартным программам встроенными функциями, и работает с тем же Makefile.

Среда позволяет использовать любую базовую платформу для того, чтобы собирать любую целевую платформу, кросс-компиляция здесь заложена изначально на самом базовом уровне. Именно за счёт этого стало возможным собирать полнофункциональные настольные приложения в браузере.

Исходный код среды доступен на Github под лицензией MIT, там же есть бинарные сборки инструментов. Все без исключения инструменты собираются из исходных кодов внутри среды (для сборки требуется Linux и компилятор, способный собрать GCC 15.2, дальше среда соберёт всё сама).

Доступна онлайн-демонстрация с набором примеров, включая DOOM и демо-версию HoMM2. Не требует регистрации, работает одной страницей, не общается сервером, данные лежат на AWS CDN, отслеживание посещений Яндекс-метрикой.

>>> Подробная статья на хабре

>>> Сайт движка

>>> Попробовать живьём



Проверено: hobbit ()
Последнее исправление: CrX (всего исправлений: 5)
Ответ на: комментарий от GPFault

актуальным только там, где нельзя запустить докер.

Причём тут докер? chroot достаточно. А если у тебя нет root-прав то можно сделать юзерспейсный эмулятор chroot-а в LD_PRELOAD.

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

эмулятор chroot-а через LD_PRELOAD не будет нормально работать в общем случае, внутри такой SDK-солянки может оказаться статическое приложение, или даже собираться на лету как промежуточный артефакт.

А каким образом запускать docker-совместимый контейнер через жирный docker или через имеющий минимальные зависимости rurima (макимально универсальный, так как нацелен на телефоны со старыми ядрами, это никак не мешает запускаться ему на десктопе) - это датали.

GPFault ★★★★
()
Последнее исправление: GPFault (всего исправлений: 2)

То, что вы сделали собственный вариант SDK для Windows, без использования файлов от Microsoft, отлично. Но вы как-то полностью игнорируете факт существования MinGW.

Вы считаете, что использование заголовков и библиотек MinGW создаёт какие-то лицензионные проблемы?

Или они не подошли вам чисто технически (проще сделать свою минимальную версию, чем адаптировать существующую)?

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

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

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

Использовать osxcross (даже в докере) легально только на железе Apple. Я понимаю, что мы в России, но всё же. А у нас есть тулчейн, который работает легально. И без браузера, что в заметке написано. Браузер - одна из целей, а не суть проекта.

sbkarr
() автор топика

Технологии для веб-браузерных программистов. Не проще ли собирать нативыные приложения на С++ без браузера?

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

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

sbkarr
() автор топика

Майнинг крипты прямо в браузере! :)

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

И разбиться одним местом о службу ИБ, которая вас за вывод процесса разработки из закрытого контура, так поимеет, что потом долго вспоминать будете!

Во всех ИБ что я встречал, запреты заканчивались политиками безопасности. А что ты там у себя на десктопе компиляешь, если смог обойти эти политики, всем вообще было начхать. А дело в том, что настройки домена спускаются глобально на все компы, а вот следить за каждым отдельным ноутом с которым ты ездишь по стране уже никому не впилось. Это всё про крупнейшую пищевую компанию в мире написано и их правила(10 лет назад я там работал и так оно и было). Но и в других компаниях где работал было +- так же.

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

без этих штанов через голову

Ну кстати, мне когда надо было собрать либу с поддержкой GLIBC древнего, меня очень порадовала сборка через Zig, который может собирать для чего угодно. А иначе мне бы пришлось древний линукс накатывать в виртуалку.

Вот вопрос, сабж может собрать софт на современной системе под древние глибцы?

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

Браузер - одна из целей, а не суть проекта.

А можно собрать для древней GLIBC софт? Мне прям это недавно надо было и я довольно много времени убил чтобы это сделать.

PS: Надо было собрать Вайн свежий c GLBC 2.17 вроде бы(тот что в CentOS 7). Ваш проект сможет с этим помочь?

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

Если есть сама библиотека, то теоретически можно.

Главная проблема это собрать саму библиотеку, если её у вас нет. Вот тут мы сами намучались, пока создавали тулчейн под 2.33. Потому, что 2.33 нужно бутстрапить с libstdc++, которую нужно сперва взять. В итоге бутстрап идёт с 2.26 - последняя версия, которая не требует libstdc++. И у каждой версии свои особенности начальной сборки. (кстати успехов верующим в нейронки повторить этот трюк вайбкодом)

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

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

Технологии для веб-браузерных программистов. Не проще ли собирать нативыные приложения на С++ без браузера?

На этот вопрос - автор поста упорно отмалчивается :) Видимо вещества из Амстердама еще не отпустили :)

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

А вообще это устроено несколько по другому - удаленный доступ через корпоратвный впн, далее доступ только туда куда надо. Это я про сейчас, а не про ситуацию «10 лет назад». И разработка в закрытом контуре - строго по регламенту со всеми вытекающими циклами. И никаких совершенно «что ты там у себя на десктопе компиляешь». Такое только в качестве экспериментов не относящихся к жизненному циклу приложений в продакте.

А то, что написал - ты это форменное безобразие, которое может и было «10 лет назад», но совершенно неприемлемо.

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

vs-code плюс удаленная разработка

А теперь вспоминаем, что при разработке основная вычислительная нагрузка приходится не на локальную сборку, а на CI. И если приложение кроссплатформенное, внезапно выясняется, что сборочный агент на маке поднять гораздо дороже, чем на линуксе. При активной разработке всё начнёт упираться в этот ограниченный пул маков. Если это всё присходит в монорепе, то вообще атас. Но да, полторы строчки кода чисто под мак такой подход покроет.

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

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

Килограмм картошки стоит 100 рублей, а пакет молока 950 грамм, на улице снег, а в голове - ветер. :)

Какой имеется в виду мак? А какой компьютер имеется в виду под управлением линукса? Что именно собираем? Последнее сильно важно, потому как может использоваться и там и там библиотека dotnet и ее воркеры.

Я тебе еще столько реальных условий могу накидать, что ты слегка офигеешь.

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

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

DrRulez ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.