Войти
ФлеймФорумПроЭкты

Ü (Programmiersprache) (39 стр)

Страницы: 134 35 36 37 38 39
#570
(Правка: 22:44) 22:41, 9 ноя. 2019

Panzerschrek[CN]
> Сейчас вот надо придумать, как бы сделать так, чтобы всякие функции сишной
> стандартной библиотеки были доступны из браузера. Думаю, без emscripten тут не обойтись.
чоа? а c-runtime под webassembly от llvm не доступен?
я бы вытягивал из браузера браузерные вещи - типа WebGL, может быть манипуляцию с DOM-ом, клава, мышь... что ещё для геймдева нужно :)

просто, если C-runtime тянуть через webassembly, то получится неэффективно.
Т.к. это нужно будет делать через импорт.
WebAssembly->JS->WebAssembly
или ещё хуже, реализовывать в самом JS-е.


#571
22:55, 9 ноя. 2019

skalogryz
> WebAssembly->JS->WebAssembly
Глянул в emscrtipten. Походу, они таки всё что можно, компилируют из C в WebAssembly, а через импорты тянут только самое необходимое.

> c-runtime под webassembly от llvm не доступен?
Быстрый поиск не дал результатов. Да и с чему бы ему там быть? C рантайм это glibc.

> или ещё хуже, реализовывать в самом JS-е.
Какой-нибудь printf на нём придётся реализовывать. Всё остальное - в нормальном языке (Ü, C, C++).

#572
(Правка: 23:09) 23:09, 9 ноя. 2019

Panzerschrek[CN]
> Какой-нибудь printf на нём придётся реализовывать.
ооо! printf() это вообще боль для webassembly
сигнатура функции с фиксированным количеством и типом параметрова должна быть известна заранее;
т.е. функцию с произвольным количеством параметров (переданных через стэк) реализовать не получится.
как минимум, нужно будет организовать массив с укаталеями на параметры; либо городить кучу overload-ов, что не вариант.
(хз как оно в :U)

имхо, проще реализоывать WriteConsole(char* buf, int len) в JS-е, а основное тело printf() в WebAssembly.

#573
12:23, 10 ноя. 2019

Прохладные истории продолжаются.

После перехода на llvm 9 начали валиться сборки на travis-ci. Новый llvm жирнее старого и его сборка не умещалась в лимит.
Решил собирать проект с предсобранным llvm - скачал его, настроил файл проекта под возможность собираться с готовым llvm.
Беда пришла откуда не ждали - компилятор валится на такой фигне:

undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
undefined reference to `typeinfo for llvm::cl::generic_parser_base'
undefined reference to `typeinfo for llvm::cl::Option'

Расследование показало, что всему виной rtti. Бинари llvm собраны без него, а мой проект - с ним. Но почему стреляет только в том месте? А потому, что там в заголовочном файле объявлен шаблонный класс, наследуемый от нешаблонного. Для того нешаблонного класса компилятор ожидает, что кто-то для него создаст rtti. Но при компиляции llvm его никто не создал.

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

#574
20:40, 13 ноя. 2019

Таки закостылил проект, чтобы он без rtti работал. Костылей, как оказалось, много не понадобилось. При грамотном подходе dynamic_cast почти не нужен.
Теперь проект собирается с предсобранным llvm на travis-ci. Теперь переходу на llvm-9 ничего не мешало и я залил ветку в master.

#575
20:41, 13 ноя. 2019

В заметках о выпуске llvm заметил такой интересный пункт - "проекты с открытым исходным кодом, использующие llvm ${номер_версии}". Надо исследовать, как бы туда можно попасть.

Страницы: 134 35 36 37 38 39
ФлеймФорумПроЭкты