OberonCore

Итак, что мы имеем на данный момент?



В дальнейшем планируем дополнить интерфейсом перечислителей - чтецов.

Всё так?

Перечислитель через next простой? Ну и его в Dev, наверное, надо поместить. DevLib, к примеру.

В Dev то зачем? Другим сервисам внутренним он не пригодится в отсутствии Dev?

А каким, например? У Евгения Карта, в Dev есть Repository, у меня в EdTools перечислитель будет, пожалуй, использоваться. Это все разработческие инструменты.

А... если припомнить рассказ Евгения, то получается, что он хотел для конфигуратора запуска использовать его. Тогда надо не в Dev. Ну тогда получается StdLibrarian?

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

Ну не перечислитель, а библиотекарь. Так можно в запуске Setup будет установить другую реализацию Librarian, что если скажем подсистема Host то, брать из HostWin при одной конфигурации и HostLin из другой... Так будет как у Евгения/Петра/Ивана, все хосты лежать в одной сборке ББ. При этом сами модули иметь названия HostConsole и т.п.

Вообще-то в таком случае получается, что библиотекарь должен быть частью модуля StdLoader...

Там как раз есть процедура ThisObjFile, которая должна быть реализована через библиотекарь.

Ну частью, наверно, нет. А вот то, что он в Std должен находится, пожалуй, согласен. Ещё бы мнение тов. Темиргалеева на этот счёт услышать.

Дело в том, что StdLoader линкуется в пускач, и поэтому если выделить отдельный модуль, то опять получим расширение зависимостей.
У нас ведь уже HostEnv и Utf (в версиях для ~ Windows) появилились в списках линковки. А так ещё и StdLibrarian будет. А так, если в состав StdLoader включить, то не придется расширять список для линковки.

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

Импорт будет лишь в подсистеме Dev. А в пользовательских программах обычно этой подсистемы нет. Так что не такая большая проблема.

Скажем так. StdLoader может быть и не доступен, если его функции выполняет другой модуль.

А давайте его сразу в Kernel засунем.
Подсказка: всегда можно создать NonStdLoader.

Кстати да...
Kernel.LoaderHook
Если использовать эту штуку, то конфигуратор запуска может установить альтернативный загрузчик, в котором импортирован библиотекарь.
Так что не обязательно StdLoader менять.

Считаю, что библиотекарь должен быть отдельным модулем. Подсистема Std для него подходит (StdDialog.GetSubLoc). Реализацию библиотекаря не стоит делать ни частью StdLoader, ни его альтернативной версии. Замена механизма поиска не обязтельно подразумевает замену механизма загрузки.

Если говорить про внедрение библиотекаря на уровне ББ, то отсюда логично вытекает, что StdLoader должен работать через него. Я представлял себе это как обращение к библиотекарю в StdLoader.ThisObjFile.
Можно сохранить старую версию StdLoader, а новую назвать по-другому. Это позволит собирать пускачи со старой схемой работы без библиотекаря, если это кому-то требуется.

Не представляю, как можно обойтись без линковки библиотекаря с его реализацией в пускач. Схема, когда в пускаче старый StdLoader, а Init выставляет новый не полноценная, потому что тогда библиотекарь не сможет выбирать Init. А этот модуль варьируется в каждой сборке -- он разный для консоли/графики в линуксе, винде и т.д.

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

Меня смущают следующие моменты:
1) Предусловие, проверка которого требует импорта Kernel. Не уверен, что это обязательно необходимо для каждой реализации. Я бы не накладывал на эти цепочки никаких ограничений, потому что именно реализация определяет, как их отображать на конечные координаты.
2) Результаты "нашел", "не нашел" не достаточны. Должен как минимум быть еще один -- "ошибка". Если добавить OUT res: INTEGER к GetSpec или добавить res*: INTEGER к Librarian (как в Files.Locator), мы получим возможность передать штатные коды "нашел", "отсутствует", "ошибка" -- допустим 0, 1 и 2, и любые другие специфические для реализаций.

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

В сборке с вариантными модулями (https://oberoncore.ru/library/temir_core-vmod) хотя и неявно (без интерфейса библиотекаря) реализованы две разные схемы правил для компиляции/линковки и загрузки.

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

Хм... да, что-то я лишнего написал... они были бы нужны для OUT Параметров, но это же IN. Пожалуй, согласен: не нужны эти предусловия.


Да, поддерживаю, давайте добавим поле res*: INTEGER с кодом ошибки.

Получается:

Я представлял себе это следующим образом:

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