OberonCore
https://forum.oberoncore.ru/

предложение по реорганизации системозависимых частей
https://forum.oberoncore.ru/viewtopic.php?f=134&t=6893		 Страница 2 из 3
Автор:  arisu [ Понедельник, 06 Февраль, 2023 14:34 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Борис Рюмшин писал(а):
А с компиляцией как? Тоже символьники по архитектуре искать?
да, и символьники, и объектники. они сразу компилятором раскладываются в arch-подкаталоги. именно для этого нужен вызов "DevCompiler.SetCrossArch XXX" — он перекрывает значение текущей архитектуры, чтобы компилятор в правильные места выхлоп складывал (ну, и в правильных местах исходники искал). по-умолчанию crossArch пустая (то есть, равна рабочей).
Автор:  arisu [ Понедельник, 06 Февраль, 2023 14:39 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Борис Рюмшин писал(а):
Прямой импорт Host* это плохо всегда и везде.
да, это я опять криво описал. из Host будет импортировать некий «общий модуль системной инициализации», конечно. который тоже Просто Импортируется.

то есть, по сути — в некоторых местах мы избавляемся от `Dialog.Call`, потому что среда сама загрузит нужное. а в остальных остаётся примерно так же, как и сейчас, но вместо копипасты «общего модуля инициализации» для каждой архитектуры — его можно сделать общим с обычными импортами, и среда опять разрулит. (по-моему, снова не очень понятно вышло.)
Автор:  arisu [ Понедельник, 06 Февраль, 2023 14:43 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
а насчёт этажерки из путей… ну, всего один дополнительный подкаталог. по-моему, не очень страшно. немного доработать среду, чтобы в заголовке окна показывало, если открыто из "Mod/Win/" — «[Win]», например, чтобы не путаться — и, в принципе, больше особых неудобств быть не должно. тем более что подобные этажерки в "Mod/" нужны только в Host и ещё чём-то системно-зависимом, а прикладной код как обычно лежит просто в "Mod/". а что там внутри "Code/" и "Sym/" происходит — про то программисту вообще ни думать, ни знать не надо, а надо использовать предоставляемые средой средства — браузер там, и прочее. а они разберутся, что и как.

зато извне среды — тоже сразу видно, что к чему относится, и красиво разложено. бери, например, и автоматическими командами собирай дистрибутивы под разные ОС, не перечисляя руками, что к чему относится.
Автор:  arisu [ Понедельник, 06 Февраль, 2023 14:53 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
признаюсь честно: основной мотивацией были две вещи.

во-первых, мне не нравится, что корень засоряется подсистемами под каждую новую архитектуру. эти подсистемы, по сути, для использования в прикладном коде не предназначены, но они там болтаются и мешают. вместо этого я их хочу сложить обратно в Host: будет одна подсистема Host, про которую все знают, что из неё импортировать не надо. а что там у неё внутри происходит — то пользователя не касатеся, это как раз Чёрный Ящик, который обеспечивает взаимодействие ОС ↔ BBCB.

и во-вторых, я всё-таки думаю о Светлом Будущем, когда у нас будет не только x86. и тогда существующая техника кросс-сборки просто сломается, потому что пишет .ocf сразу в "Code/". и тогда всё равно придётся .ocf для разных процессоров как-то разделять. можно добавлять расширение, а можно делать отдельный подкаталог. я сделал подкаталог, потому что мне кажется, что так удобней и меньше путаницы будет в итоге.

ну, и всё это в основном подвязано на StdLibrarian вдобавок, который и планировался для выделения алгоритмов получения путей в отдельный интерфейс. за исключением некоторых мест в DevCompiler и DevPacker (их тоже можно будет потом сделать через StdLibrarian, я просто пока до этого не дошёл), и в StdLoader, куда я библиотекаря импортировать не хочу. то есть, основной код получается вдобавок ещё и чище — потому что ходит с вопросами про пути в Правильное Место. а Правильное Место разруливает всё остальное.
Автор:  SovietPony [ Понедельник, 06 Февраль, 2023 15:23 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
arisu писал(а):
DevCompiler.SetCrossArch XXX
Для кросскомпиляции предпочитаю явные опции к компилятору для установки кодогена и сисрута, а по дефолту всегда хост. Со спрятанным текущим таргетом постоянно путался и что-нибудь не там ломал, но то было без глубокой интеграции в среду.
arisu писал(а):
Dialog.Call
Без громоздкого Dialog.Call для подобных целей и так можно обойтись почти всегда, в Kernel есть легковесный интерфейс для загрузки модулей и команд.
arisu писал(а):
ну, всего один дополнительный подкаталог.
С хостами понятно, а с архитектурами как? Есть у нас условный Lin и хотим его собрать для 386, arm, powerpc, а еще через условный cpfront/llvm на какую-нибудь ж... куда сгружать объекты? а еще могут быть разные аби (на армах softfloat/hardfloat и т.д.) для одного хоста и процессора, что с нимим? А там и ещё что-нибудь платформоспецифичное...
Автор:  arisu [ Понедельник, 06 Февраль, 2023 15:38 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
SovietPony писал(а):
arisu писал(а):
DevCompiler.SetCrossArch XXX
Для кросскомпиляции предпочитаю явные опции к компилятору для установки кодогена и сисрута, а по дефолту всегда хост.
это можно без проблем сделать, `DevCompiler.SetCrossArch` просто читает параметр и вызывает `Kernel.SetCrossArch()`, никакой другой магии. можно добавить и явные опции. я сделал так, потому что мне так было удобней, и меньше кода модифицировать.

SovietPony писал(а):
Со спрятанным текущим таргетом постоянно путался и что-нибудь не там ломал, но то было без глубокой интеграции в среду.
ну, если с интеграцией в среду — то можно допилить показывание кросса. или вообще как угодно допилить, механизм простой.

SovietPony писал(а):
С хостами понятно, а с архитектурами как? Есть у нас условный Lin и хотим его собрать для 386, arm, powerpc, а еще через условный cpfront/llvm на какую-нибудь ж... куда сгружать объекты? а еще могут быть разные аби (на армах softfloat/hardfloat и т.д.) для одного хоста и процессора, что с нимим? А там и ещё что-нибудь платформоспецифичное...
я думал про добавление `subArch`, но не стал этого пока делать чтобы не пилить сразу кучу всего. однако добавить такое в систему будет несложно, поскольку основная магия вся в одном месте сосредоточена. будет ходить, например, в "Subsys/Mod/arch-subarch", если там нет, то в "Subsys/Mod/arch", если и там нет — в "Subsys/Mod". какие угодно схемы можно будет реализовать, руками придётся править только StdLoader, в одном единственном месте. и то — я, может, и его на библиотекаря пересажу, почему бы и да.

или просто сделать архитектуру вида "ArchSub", и сначала смотреть в "ArchSub", а потом в "Arch". куча вариантов, выберу один когда понадобится.
Автор:  Борис Рюмшин [ Понедельник, 06 Февраль, 2023 17:00 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
arisu писал(а):
SovietPony писал(а):
С хостами понятно, а с архитектурами как? Есть у нас условный Lin и хотим его собрать для 386, arm, powerpc, а еще через условный cpfront/llvm на какую-нибудь ж... куда сгружать объекты? а еще могут быть разные аби (на армах softfloat/hardfloat и т.д.) для одного хоста и процессора, что с нимим? А там и ещё что-нибудь платформоспецифичное...
я думал про добавление `subArch`, но не стал этого пока делать чтобы не пилить сразу кучу всего. однако добавить такое в систему будет несложно, поскольку основная магия вся в одном месте сосредоточена. будет ходить, например, в "Subsys/Mod/arch-subarch", если там нет, то в "Subsys/Mod/arch", если и там нет — в "Subsys/Mod". какие угодно схемы можно будет реализовать, руками придётся править только StdLoader, в одном единственном месте. и то — я, может, и его на библиотекаря пересажу, почему бы и да.

или просто сделать архитектуру вида "ArchSub", и сначала смотреть в "ArchSub", а потом в "Arch". куча вариантов, выберу один когда понадобится.

Ну вот примерно, как SovietPony и сказал, у меня такие же вопросы к подкаталогам. А тек, заход, повторюсь, мне довольно близок))
Автор:  arisu [ Понедельник, 06 Февраль, 2023 18:24 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Борис Рюмшин писал(а):
Ну вот примерно, как SovietPony и сказал, у меня такие же вопросы к подкаталогам.
собственно, оно уже на горизонте: у нас есть Win и Win/MDI, которые неплохо бы иметь отдельно (хотя бы как опцию). скорее всего, сделаю, чтобы arch делилось по второй заглавной букве на subarch ещё.

кстати, перевёл и StdLoader на библиотекаря: теперь вообще вся магия в одном месте собрана. правда, надо пройтись по всему коду и в остальных местах как минимум загружалки ресурсов тоже на библиотекаря перевести ещё. и проверить инструментальные модули в Dev, чтобы тоже по инстанции обращались все, а не занимались самодеятельностью.

собственно, кому подкаталоги не понравятся — то просто переделает StdLibrarian на любую другую схему, и всё. для того всех и заставляю туда ходить.
Автор:  arisu [ Понедельник, 06 Февраль, 2023 21:52 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
для эксперимента выделил виндовую Mdi в «составную» архитектуру WinMdi. опять же, можно посмотреть в репозитории, "Mdi" переехало в "Win/Mod/WinMdi". пока не починена загрузка менюшек и прочих ресурсов, правда, надо запихать библиотекаря. зато добавил поддержу «составных архитектур». все системно-независимые модули для Win так и живут в "Code/Win", и только сама "Win" собирается в двух вариантах: "Code/Win" и "Code/WinMdi".

не уверен, что это лучшее из возможных решений, но зато оно Просто Работает (опять таки).
Автор:  Борис Рюмшин [ Вторник, 07 Февраль, 2023 00:14 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Ну а почему оно должно не работать?
Автор:  arisu [ Вторник, 07 Февраль, 2023 01:01 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Борис Рюмшин писал(а):
Ну а почему оно должно не работать?
это я имел в виду, что не понадобилось вводить новых переменных и прочая, просто чуть-чуть подрихтовал StdLibrarian. и заодно убедился, что ничего там по дороге не забыл. ;-)

алсо, перевёл DevSearch, DevReferences и StdMenuTool на использование StdLibrarian. теперь они корректно понимают перекрытие основных ресурсов архитектурно-зависимыми (Mdi-меню теперь автоматически появляется только в Mdi-бинарнике), Search in Sources и Search in Docu корректно ищут в архитектурно-зависимых исходниках и документации (ежели таковые есть).

p.s.: и Dialogs, за строковыми ресурсами теперь ходит тоже через StdLibrarian.
Автор:  arisu [ Вторник, 07 Февраль, 2023 02:54 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
переместил "Win" обратно в "Host". кросивое. даже собралось и запустилось. кое-где фиксы свелись к тому, что вместо чего-то типа "HostFonts := WinFonts" вернул старое "HostFonts", гыг.

всё, все остальные (Lin, Fbsd, Obsd) унёс туда же. ура мне, принесите бокалы — я их буду бить, уберите сено из овина — я сожгу овин.
Автор:  arisu [ Вторник, 07 Февраль, 2023 07:29 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
и сборочный скрипт теперь выглядит примерно так:
Код:
echo "compiling common base system"
sh ./run-dev0 $DEVARG <<DATA
DevCompiler.SetCrossArch $ARCH
DevCompiler.CompileSubs Host System Std Cons Text Form Dev Com Comm Ctl Sql Ole Obx Diff Lamentdev Lament
Kernel.Quit(0)
DATA

echo "linking GUI"
sh ./run-dev0 $DEVARG <<DATA
DevCompiler.SetCrossArch $ARCH
DevLinker1.LinkElfExe * blackbox := Kernel$+ Utf HostSubArch HostKernel Files HostEnv HostFiles HostGui StdLibrarian StdLoader HostLoader  1 BlackBox.res 1 Applogo.ico 2 Applogo.ico 3 SFLogo.i
co 4 CFLogo.ico 5 DtyLogo.ico 6 folderimg.ico 7 openimg.ico 8 leafimg.ico 1 Move.cur 2 Copy.cur 3 Link.cur 4 Pick.cur 5 Stop.cur 6 Hand.cur 7 Table.cur
Kernel.Quit(0)
DATA

echo "linking console interpreter"
sh ./run-dev0 $DEVARG <<DATA
DevCompiler.SetCrossArch $ARCH
DevLinker1.LinkElfExe * dos blackboxInterp := Kernel$+ Utf HostSubArch HostKernel Files HostEnv HostFiles StdLibrarian StdLoader HostIntLoader  1 BlackBox.res
Kernel.Quit(0)
DATA

if [ "z$ARCH" = "zWin" ]; then
echo "compiling and linking Windows/MDI system"
sh ./run-dev0 $DEVARG <<DATA
DevCompiler.SetCrossArch "${ARCH}Mdi"
DevCompiler.CompileSubs Host Ole
DevLinker1.LinkElfExe * blackboxMDI := Kernel$+ Utf HostSubArch HostKernel Files HostEnv HostFiles HostGui StdLibrarian StdLoader HostMdiLoader 1 BlackBox.res 1 Applogo.ico 2 Doclogo.ico 3 SFL
ogo.ico 4 CFLogo.ico 5 DtyLogo.ico 6 folderimg.ico 7 openimg.ico 8 leafimg.ico 1 Move.cur 2 Copy.cur 3 Link.cur 4 Pick.cur 5 Stop.cur 6 Hand.cur 7 Table.cur
Kernel.Quit(0)
DATA
fi


один раз делаем `ARCH="…"`, например — и всё Просто Собирается. только хак для Mdi остался. поскольку Com, Ole, Sql и прочее чисто виндовое и живёт теперь в "Mod/Win" — то для линуксов сборщик просто сделает с ними ничего (с его точки зрения там пусто).

я не знаю: если это менее удобно и более сложно, чем ручные танцы с бубном — то я тогда не понимаю, что такое «просто».

да, `DevLinker1.LinkElfExe *` проверяет crossArch, и вызывает `DevLinker.Link` с остатком аргументов. потому что мне надоело иметь там явное условие для того, что машина может понять сама.

замечу, что всё ходит через доработаный StdLibrarian; и всяческие «посмотреть исходник», «посмотреть документацию» и ты пы — тоже прекрасно работают, открывая именно то, что надо. и строковые ресурсы тоже через StdLibrarian, так что тоже подтягиваются правильно, с учётом возможных архитектурных перекрытий.

а для документов из подкаталогов, типа "Subsys/Mod/Win/MyMod.odc" — среда ставит заголовок окна вида: «(Subsys)MyMod - [Win]». не заблудишься.
Автор:  Борис Рюмшин [ Вторник, 07 Февраль, 2023 13:08 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
А чего вы модули Sql в Win то отправили? Они кроссплатформенные вроде (в основном).
Автор:  arisu [ Вторник, 07 Февраль, 2023 14:41 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Борис Рюмшин писал(а):
А чего вы модули Sql в Win то отправили? Они кроссплатформенные вроде (в основном).
это-то да, но драйверов под линуксы к ним нет ведь пока. как только драйвер появится — можно будет сразу обратно вытащить, дело-то плёвое. их, собственно, по этой причине и в mainline под не-винду не собирают (там не собирают), я так понимаю.

и сразу налетел на мелкую гадость, гыг: кросс-ссылочки в перемещённой документации перестали работать. надо туда тоже приделать поиск, не менять же каждый документ руками.
Автор:  Борис Рюмшин [ Вторник, 07 Февраль, 2023 16:12 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Почему нет? Есть подсистема Mysql, которая реализует соответствующий драйвер под обе платформы.
Автор:  arisu [ Вторник, 07 Февраль, 2023 21:25 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
Борис Рюмшин писал(а):
Почему нет? Есть подсистема Mysql, которая реализует соответствующий драйвер под обе платформы.
в основном репозитории нет, а я о ней не знал в силу мне её ненужности. можно ссылочку? посмотрю, верну обратно, спасибо за уточнение.
Автор:  Борис Рюмшин [ Вторник, 07 Февраль, 2023 21:52 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
https://oberoncore.ru/bbcc/subs/mysql/start
В каком оно сейчас состоянии не отвечу.
Автор:  arisu [ Вторник, 07 Февраль, 2023 22:33 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
спасибо! чот я мог бы и сам догадаться поискать, а не напрягать. старость-с… посмотрю по возможности.
Автор:  arisu [ Среда, 08 Февраль, 2023 00:16 ]
Заголовок сообщения:  Re: предложение по реорганизации системозависимых частей
там, по ходу, драйвер только для винды реализован. думаю, адаптировать можно, но мне сейчас немного не до этого, увы.
Страница 2 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/