OberonCore

Раздел про МультиОберон на форуме центра.

Вышла версия 1.0.
Основные изменения:
1. Откорректирована динамическая загрузка Oml и реализована в Omf;
2. Реализованы ombsh,omfsh,omlsh для динамической загрузки и выполнения;
3. Поддерживается тестирование, бенчмаркинг;
4. Усовершенствована сборка, особенно для кросс-платформенных приложений.

Отличная новость. И динамическая загрузка тоже радует!

Там как-то в геометрической прогрессии растёт число скриптов и обозначений файлов на внутреннем кодовом языке.
Можете дать простой алгоритм, как из вашего проекта оставить скажем только Linux LLVM ? Чтобы всё остальное просто удалилось пока... надо ведь с чего-то начинать.

Плюс проекта в наличии документации. Возникла идея, сделать программу, которая генерирует документацию отдельно для Linux, отдельно для Windows. Так будет намного легче читать и понимать её.

Нет там языка, кроме Оберона.
Скрипты .bat, .sh - просто команды.


Binue оставьте, если 32-бит
Binur оставьте, если 64-бит
остальные Bin* удалите (но кросс-сборка где-то перестанет работать).

А так, надо инсталлятор с галочками делать, а не zip с гитхаба. Но его надо делать (не знаю, можно ли к текущим исходникам на гитхабе приклеить). Та же самая история с линуксом - пакет делать, так везде пакетные менеджеры разные (тоже не смотрел, можно ли к текущим исходникам на гитхабе приклеить создание пакета).


Linux - голубой цвет, Windows - коричневый, для всех платформ - черный.

Если, всё же, захотите сделать, смотрите rpm - более адекватный с технической стороны, является стандартом для Linux и можно конвертировать в deb. Или snap/flatpak - проще в создании и поддержке и работают во всех распространённых дистрибутивах. Сделать один раз для почти всех дистрибутивов вполне возможно, а пользователи особых изысков сами соберут.

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

Пытаюсь установить Мультиоберон по инструкции (на новом Убунту на x64).
При вызове команды lin_toinstall.tcl выдаёт ошибку:

0. Предполагается, поддержка 32-бит у Вас есть и BlackBox Вы поставили
1. Проверьте наличие Binue/ombc - в архиве он есть
2. Запустите из консоли Binue/ombc co -h -odc -wsd -ne Api_bue OStrings_bu OLog_bu Runner_bue17 Times Testing Baseloader_17 HostApi_bue HostConLog_bu HostTimes_bue
3. Если прошло, и остальные строчки из lin_toinstall без exec!
4. Отвечайте тогда не в главную тему, а в вопросы по использованию.

Не знаю, насколько уместно писать это здесь, но для создания "инсталляторов с галками" есть https://makeself.io/, мы используем на работе.

Попробовал установить на другом компьютере, с Дебианом. Получил вот такую ошибку:

error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory while executing...



[ОБНОВЛЕНИЕ 1]

В интернете посоветовали поставить libncurses5-dev:



Не помогло.

[ОБНОВЛЕНИЕ 2]

Прочитал в документе (почему-то ниже по тексту это написано, а хотелось бы выше по тексту), что нужен clang. Сделал следующее:



Не помогло.

[ОБНОВЛЕНИЕ 3]

Попробовал поставить libtinfo5, на которую оно жалуется. Она уже есть.



[ОБНОВЛЕНИЕ 4]

Без указания версии ещё есть dev-версия этого пакета.



Снова не помогло.

Вот ещё в таком варианте встречается ошибка:

На вопросы по использованию отвечаю в теме https://forum.oberoncore.ru/viewtopic.php?f=157&t=6641&p=113384#p113384

Дмитрий, в ответах на вопросы к своему докладу Вы говорите, что BlackBox можно перенести на MultiOberon и собрать его 5-ю компиляторами, но не делаете этого, потому что нет времени. В скольких человеко-днях оцениваете эту работу?

Месяца в три, мне кажется. Версию portable, без Omf, возможно, он больше с консолью связан.

То есть, приблизительно через 3-и месяца работы в нормальном режиме можно было бы получить полноценную версию BlackBox для AMD64 и ARM?

AMD64. ARM я пока не делал, хотя думаю.

Генерируемый код для LLVM заточен под x86?

LLVM генерирует байт код и об'ектники для выбранной целевой платформы.

А, помню, Вы отказались от идеи генерировать биткод самостоятельно, а положились на библиотеку, потому что это более стабильная точка связывания. Или llvm принципиально не позволяет получить биткод не завязанный напрямую на целевую платформу?

Все правильно, через библиотеку, которая генерирует портабельный биткод. Условно портабельный, т.к. метаданные разнятся по размеру для 32 и 64. Но далее можно выбрать целевую платформу и сгенерить об'ектники. Oml может запустить программу llc с выбором платформы, например x64. Либо прямо через библиотеку генерить для платформы по умолчанию.

А в чём различие в метаданных?