OberonCore

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

вступление

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


описание

вводим понятие «название архитектуры» (строковый глобал arch) и делаем его интегральной частью путей поиска. поясняю: если у нас архитектура «Lin», то путь поиска кодовых файлов будет таким, например:
Subsys/Code/Lin/*.ocf
символьных:
Subsys/Sym/Lin/*.osf
you got the idea.
с исходными файлами почти то же самое, но с маленьким нюансом: сначала смотрим в Subsys/Mod/Lin, а потом в Subsys/Mod. таким образом мы можем иметь модуль с названием HostKernel, который магически будет разным для разных платформ. но с одним названием. но не всё в куче.

для компилятора вводится ещё одна переменная: crossarch. если она не пустая — то это название архитектуры, для которой собираем. тогда компилятор пользуется не arch, а этим вот. ну, понятно зачем.


что имеем с барашка

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

второе. мусорить в корень отдельной подсистемой на каждую архитектуру — не дело. с моим предложением мы возвращаем подсистему Host, и складываем все системно-зависимые части в неё, как и было заповедано Великими Отцами. насколько надо делать новый хост совместимым со старым — вопрос для отдельного обсуждения. становится чисто, красиво, и никакой проблемы с тем, что подсистема для какой-то будущей архитектуры будет конфликтовать с чьей-то уже существующей.

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


детали реализации

хитрый поиск предлагаю реализовать в Files, чтобы основной код знать не знал, что есть какие-то специальные архитектуры. код ходит в обычные Subsys/<Mod|Code|Sym|Rsrc|Docu>, а среда делает остальное. spiritually примерно так же, как сделаны /USE и /CUSTOM. Mod-подобный поиск (сначала с arch, потом без arch), в принципе, имеет смысл сделать для вообще любого подкаталога подсистемы. то есть, для чего угодно вида "Subsys/dirname". для "Code" и "Sym" оно смысла не имеет, но и мешать не будет, так что можно не заморачиваться их отдельной обработкой.

в DevCompiler потребуются небольшие изменения, которые можно сделать через StdLibrarian, расширив его интерфейс. конкретно — библиотекарь должен не просто возвращать локатор, а иметь апи «открыть существующий файл» и «создать новый файл». тогда всю логику поиска можно унести в библиотекаря, и не портить ней код компилятора.

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


contra

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

также в систему добавляется некоторая усложнённость и неочевидность, но она — по моему важному мнению — минимальна, а профиты даёт хорошие.


заключение

я сейчас работаю над переводом Lament Configuration на эту систему. в процессе реализации побегаю по граблям — и можно будет внедрять в основную версию с минимумом шишек. считаю, что я гений, придумал лучшую идею со времён смывного туалета, и заслуживаю конфетку.


примечания
как минимум глобал arch имеет смысл класть в Kernel. потому что ядро уж точно в курсе, для какой оно архитектуры. и platform переместить туда же, а в Dialog просто сделать реэкспорт.

Чтобы сложное придумывать гениальности не требуется Сейчас то, что вы предлагаете решается окончаниями в названиях модулей. А раз есть решение, то и в общий дистрибутив не требуется вносить архитектурной сложности. Мы с Антоном как раз разгребали, чтобы репозиторий привести в человекочитаемый вид. Сама идея папок для подсистем создавалась, чтобы руками без всяких пакетных менеджеров можно было управляться с конфигурацией Блэкбокса и сейчас это есть, и это ценно, и это надо сохранять. Но опять же, если библиотекарь под ваш проект заточите на особую организацию работы, то это же замечательно. Главное, чтобы вам было удобно.

Ну вообще говоря, система каталогов для подсистем создавалась как какой-то компромисс при реализации компонентности. Поэтому и с введением ещё одного уровня каталогов я согласится не могу.

И, кстати, посмотрите МультиОберон (viewforum.php?f=157), там Дмитрий Викторович какое-то такое решение для множества архитектур уже делал.

система каталогов, как мне видится, создавалась как раз для удобства человеков — потому что технически ничего не мешает свалить всё в кучу в корне (как и было в оригинальном обероне, где подкаталогов не было в принципе). то есть, я не вижу тут компромисса, я вижу тут решение, направленое на удобство конечного пользователя. исходя из духа этого решения, я развил его дальше.

вряд ли омики не могли понасоздавать новых подсистем в корне — однако они упорно сохраняли Host при портировании BBCB на другие системы. я предположил, что это не недосмотр, а сознательное архитектурное решение. им, видимо, часто делать кросс-сборки было не нужно, и тем более хранить собраное вместе — поэтому хватало механизма /USE. сейчас этого механизма хватать перестало, и я попытался придумать нечто похожее, сохраняя Дух Старой Школы. сложного тут нет ничего, ни разу не сложнее того же /USE в итоге.

сейчас руками управлять конфигурацией сложно, неудобно, и будет ещё сложнее с появлением других архитектур. и то, что я предлагаю, не решается окончаниями. как? если имеется в виду "mod.ocf.lin", "mod.ocf.win" — то это точно то же самое, что предлагаю я, только менее красивое и упорядоченое. в моём варианте всё упорядочено, и всё управление разными архитектурами — просто всё та же работа с подкаталогами. что именно в этих подкаталогах — по большому счёту неинтересно, система разберётся. зато в корне чисто, всё системно-зависимое красиво сложено в Host, и внутри Host разложено по подкаталогам. всё это — без изменения самого принципа подсистем.

более того: писать кросс-платформенный код с платформозависимыми частями проще. потому что не надо никаких селекторов и ухищрений, просто пишем как обычно: "IMPORT SomelibWrapper" — и система сама подставит враппер для нужной архитектуры (потому что один будет лежать в "Somelib/Mod/Lin/Wrapper.odc"/"Somelib/Code/Lin/Wrapper.ocf", другой в "Somelib/Mod/Win/Wrapper.odc"/"Somelib/Code/Win/Wrapper.ocf", и так далее). по-моему, это повышает и читаемость кода человеками, и удобство, и никак не ухудшает возможности манипулирования этим вручную. по сути, это механизм селекторов, только автоматический, который Просто Работает.

собственно, реализация этого механизма — короче моего описания. в том-то и дело, что он простой и почти неинтрузивный. но словесные описания часто усложнают картину — именно поэтому я допиливаю его в Lament Configuration, где можно будет пощупать руками живой вариант. после чего вернуться к описанию и увидеть, что сложное именно оно, потому что я традиционно не умею делать нормальные описания. ;-)

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

в общем, пусть пока лежит, а когда будет нечто для пощупать руками — можно будет критиковать более предметно.

почему я в принципе пытаюсь пропихнуть это в mainline? потому что мне кажется, что этот вариант лучше и удобней существующего, я всё равно на него перейду, и если mainline перейдёт тоже — это упростит обмен кодом между моим форком и основным. в обе стороны. ну, и просто — я считаю — будет кросивое.

Про то, что сейчас сложно конфигурировать — голословное утверждение: достаточно удалить несколько ненужных каталогов из корня репозитория. Механизм неявной загрузки был много раз раскритикован на форуме и в чате. Селекторы уже не используются прогрессивными пользователями Блэкбокса.

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

насчёт конфигурирования: собрали win, собрали lin, удалили Win — скомпилированые модули для win остались. а зачем они нужны? в моём варианте — одной командой find убрали */Win/ — и всё, никаких следов от вин-части не осталось. более того: в одном и том же корне можно будет иметь системы для x86, x86_64, ARM32, ARM64 — и они не будут конфликтовать. ну да, /USE это частично решает — но частично. я недоволен.

Через find вы также можете удалить модули с окончаниями _win.odc

но решения моего примера с SomelibWrapper так не достичь, например. ;-) если делать высокоуровневый интерфейс к чему-то, что на разных системах есть, но реализуется иначе — то мы попадаем в ту же самую ловушку, которая уже была с Host: надо дублировать ВЕСЬ код. или делать кучу boilerplate, реекспортируя динамически загруженые модули — хотя среда может это сделать прозрачно и без дополнительной работы со строны программиста вообще.

ну и да: сейчас этого "_win" попросту нет. вот у нас есть подсистема Ole, которая strictly win-only. но это совершенно ниоткуда не очевидно, это надо Просто Запомнить. в моём же варианте — от Ole останутся просто пустые подкаталоги, которые явно говорят, что этой подсистемы в lin нет. да и пустые подкаталоги можно автоматически удалить ещё одной командой/игнорировать. более того: кросс-сборка в моём варианте выглядит так: «а собери мне все подсистемы». всё, их не надо вручную перечислять в скриптах с учётом архитектуры/ос, как сейчас: компилятор сам поймёт, что надо собирать, а что нет. всё это без изменений исходников и учёта спецслучаев во фронтэнде, при помощи просто одноразового перемещения файлов в подкаталог.

Потому что это делается не так. Делается три модуля. SomelibWrapper описывает только интерфейс SomelibWrapperLin реализацию для линукса, SomelibWrapperWin для Windows, и в линкере или про загрузке модуля подгружается нужная реализация.

После сборки для Linux там тоже сейчас пустые каталоги (вернее совсем даже нет Code и Sym). Не понимаю, в чем принципиальная разница?


Иногда за такие удобства приходится неадекватно платить усложнением системы.

Оно понятно, что для удобства пользователя. Это правильно. Я акцентировал внимание на другом: компонентность они не доделали, ограничившись системой каталогов, которая не просто хранит модули, а хранит их по определённому правилу. Как делать тут правильно большой вопрос (взгляды могу тут ещё дальше разойтись). Вы предлагаете идти путём усиления (или развития) предложенной Оминками модели, но не компонентности.

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

то есть, я совершенно согласен, что части надо красиво разделять, но не согласен с тем, как они сейчас хранятся на диске. именно это второе я и пытаюсь переделать так, как мне кажется лучше. ну и, конечно, убедить всех остальных, что это действительно лучше — с успехом от переменно отрицательного до нулевого, но когда меня смущали подобные мелочи? ;-)

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

в том, что я перестал думать о том, какие подсистемы к какой ос относятся, и делать разные скрипты сборки для разных ос: достаточно указать `DevCrossbuild.Setup("win")` в начале, например, и всё. при этом в DevCompiler (или каких-либо других местах) не надо никаких явных перечислений, какая подсистема куда относится: машина имеет достаточно информации, чтобы это выяснить самостоятельно.

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

итак. что мы имеем от предварительных результатов (которые уже в Lament Configuration).

во-первых, немного переработаный StdLibrarian, в довесок к которому появился StdLibrarianEx, который занимается открытием и созданием файлов, консультируясь у StdLibrarian. компилятор больше не лазит напрямую на диск, чтобы открыть или создать что-то в Sym/Code, а вежливо просит это сделать StdLibrarianEx. DevCompiler всё ещё сканирует каталоги, но тоже за исходниками на диск не лазит, а просит StdLibrarianEx.

зачем отделил? потому что DevCompiler хочет получить Views.View, а я не хочу Views импортировать в StdLibrarian. поэтому второй модуль.

во-вторых. переделал для примера LamentdevLog. это мой личный независимый логер, который пишет строго в консоль/терминал, параллельный другим логам. его специфика в том, что он импортирует только самый минимум, даже нужные системные апи берёт из себя же. ну, чтобы его можно было почти в любом модуле использовать, если понадобится, без боязни circular dependencies. итого: в нём стало на один импорт меньше.

мелочь, скажете вы. но какой это импорт! это Dialog, который использовался для `Dialog.Call`, чтобы динамически вызвать нужный инициализатор в зависимости от ОС. и теперь импорт логера выглядит так: `SYSTEM, Strings, Base := LamentdevLogCon;`. а LogCon вот так: `SYSTEM, libc := LamentdevLogLinApi;`. а в LinApi ровно два импорта из libc: `write` и `flush`.

и у нас магически повысилась герметичность — без хуков, регистрации и смс! потому что LogCon реализует, по сути, интерфейс, который использует главный Log. но больше не надо чесать репу и руками проверять на то, под какой мы ОС, и дёргать `Dialog.Call()`.

теперь Lamentdev выглядит так:


"Code/Win/LogCon.ocf" и "Code/Lin/LogCon.ocf" — разные: один импортирует WinAPI, другой — libc. но главному логеру на это совершенно наплевать, там нет вообще ни одной проверки на ос, и ни одного отложеного вызова через `Dialog.Call()`, или другой подобный механизм. и в инит-модулях ничего добавлять не надо. оно Просто Работает. как видите, там есть главный модуль "Log", который просто импортирует "LogCon". а какую LogCon брать — среда сама знает.

также, `DevCompiler.CompileSubs Lamentdev` отлично понимает, какие модули надо компилировать. для кросс-компиляции есть вызов `DevCompiler.SetCrossArch Win`, например: его надо сделать один раз, и после этого собирать. ну, как-то так:


реализации для разных ОС не путаются, объектные файлы не путаются, из одного и того же каталога запускается как линуксовая версия, так и виндовая (через wine). можно собирать и Lin и Win версии, как лин-бинарями, так и вин-бинарями через вайн. обычными, не dev. опять таки — из одного каталога. Просто Работает.

пакер тоже подкорректирован, и пакует dev-бинари для соответствующей CrossArch. они даже после этого работают. руками в пакере архитектуру указывать не надо, по-прежнему пишем какой-нибудь "System/Code/Fonts.ocf". всё остальное делает волшебная команда "DevCompiler.SetCrossArch".

если вдруг завтра появится какой-нибудь "Arm" или "Win64" — то я добавлю соответствующий подкаталог в "Lamentdev/Mod/", и всё. и тот же арм-билд я смогу гонять через qemu, например, в режиме прокидывания системных апи, из того же самого каталога, что и другие билды. и собрать его смогу, не поломав при этом всё остальное, и не требуя, чтобы оно обязательно собиралось dev-бинарём.

теперь, если нежно обучить среду ходить за ресурсами через StdLibrarianEx — то магически появится возможность иметь как общий ресурс, так и локальные для системы. и даже перекрывать общий ресурс только для некоторых ос (потому что StdLibrarianEx сначала пытается загрузить из "dir/<arch>/", а если не выходит — тогда просто из "dir/").

в итоге получилось, что я делаю то, что и так надо: заменяю прямые походы на диск обращениями к StdLibrarian постепенно. и вся остальная механика Просто Волшебно Работает. по-моему, это называется «чистка кода и упрощение», а не усложнение. ;-)

p.s.: остальную систему я ещё на эту механику не перевёл, сделал только Lamentdev для обкатки пока. но всё остальное тоже переедет обратно в Host, и будет так же разложено по arch-подкаталогам.

опять таки напомню, что никаких планов объединять те же Kernel и прочее обратно в монолит нет: все уже введённые хуки для отделения платформо-зависимых частей останутся там же, где и были. и организация системы тоже не сильно поменяется: просто "Lin/" и "Win/" из корня переедут в "Host/Mod/Lin/" и "Host/Mod/Win/" (ну, и импорты поправлю где надо). то есть, работа по красивому разделению системы не пропадает даром, она нужна и полезна. просто изменяется расположение файлов на диске, и местами упрощается код за счёт убирания некоторых проверок на архитектуру и связывания во время исполнения (ведь кое-где оно нужно не потому что так идеологически верно, а потому что иначе сейчас в mainline не сделать).

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

А как вы корректно импортировать такие модули собираетесь?

«Lin» и «Win» не входят в имя модуля. да, это немного кривовато, и надо сделать индикатор в заголовке окна. в остальном: у нас есть модуль "HostSmth". и документы "Host/Mod/Win/Smth.odc" и "Host/Mod/Lin/Smth.odc". оба модуля — `MODULE HostSmth`. импортируются как `IMPORT HostSmth`. а дальше магия среды добавляет arch-подкаталог, потому что среда-то в курсе, на какой архитектуре запущена.

идея такая, что в "Host/Mod/*.odc" лежат как раз абстрактные интерфейсы. и модули с этими интерфейсами импортируют модули реализации, а среда (StdLoader) автоматически выбирает модуль реализации для текущей платформы. нам ни в каком виде и никогда не нужна реализация абстрактного интерфейса для Win на платформе Lin, например — поэтому автоматический выбор не нуждается в средствах обхода автоматики. именно для этого я разделил объектные файлы в "Code/" по таким же arch-подкаталогам. в итоге оно Просто Работает.

не знаю, понятно ли вышло, я старался.

собственно, мой LamentdevLog именно так и сделан: "Lamentdev/Mod/Log.odc" ожидает реализацию определённого интерфейса, в "Lamentdev/Mod/Win/LogCon.odc" и "Lamentdev/Mod/Lin/LogCon.odc" лежат системно-зависимые реализации.

вот, я приаттачил то, как оно выглядит в моей системе. я не описывал интерфейс отдельно как абстрактную запись (просто потому, что мне не надо возможности делать дополнительные реализации), но сути это не меняет: можно было и описать. главный лог-модуль ожидает от модуля "LamentdevLogCon" реализации двух процедур: "PrintChars" и "PrintLn". что архитектурно-зависимые модули и делают.

то есть, пользовательский код импортирует модули с описаниями интерфейсов, и эти модули с описаниями интерфейсов, в свою очередь, импортируют стандартные реализации этих интерфейсов. пользовательскому коду не надо знать про то, что там есть какие-то системно-зависимые штуки, этот механизм используется только самим Host. а модулям в Host с ABSTRACT-интерфейсами не надо проверять, на какой архитектуре/ос они запущены, а достаточно просто импортировать какой-нибудь HostCoolInterfaceImpl — и среда сама подставит правильную реализацию.

А зачем так сложно? В смысле абстрактных интерфейсов? В общем-то Host* это обычно и есть реализации таких интерфейсов.

это я опять криво описал. если у нас какой-нибудь Fonts, который импортирует HostFonts, например — то промежуточной части не надо, среда сразу пойдёт в "Host/Mod/Win/Fonts" или "Host/Mod/Lin/Fonts", конечно. я имел в виду общую идею: в "Smth/Mod/*.odc" лежат интерфейсы, и импортируют реализации, которые лежат где-то в "SmthOther/Mod/Win/*.odc", например. или в том же самом "Smth/", если там же реализованы.

блин, опять криво вышло, circular import же будет. извините, я что-то сегодня отменно коряво выражаюсь, не получается перевести «с кода на русский» нормально. ;-) в общем, HostMain импортирует Fonts для интерфейсов, и HostFonts для реализации. а инициализирующий модуль просто импортирует HostMain, который всё разруливает. ну, типа этого, только с более красивой гранулярностью.

Да, собственно, я не особо против такой схемы, тем более что в модельном изделии у меня с выбором архитектуры (потенциально) загрузка и осуществляется. Меня несколько напрягает этажерка из путей.
Где-то я предлагал за виндой закрепить подсистему Host для обратной совместимости, но Иван не согласился с такой постановкой -- выносить, так выносить всё.

А с компиляцией как? Тоже символьники по архитектуре искать?



Прямой импорт Host* это плохо всегда и везде.