OberonCore
https://forum.oberoncore.ru/

#046 Библиотекарь модулей
https://forum.oberoncore.ru/viewtopic.php?f=134&t=6700
Страница 4 из 4

Автор:  adimetrius [ Понедельник, 10 Май, 2021 17:01 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Коллеги,

Я реализовал тот интерфейс библиотекаря, о котором мы согласились выше, и у себя его с января встроил в компилятор. Никаких нареканий по интерфейсу и реализации, я его опубликовал в ветку dev20.

Но далее я взялся встраивать библиотекарь в компилятор-песочницу, еще Иван Андреич сделал переход к трехслойной файловой системе (USE/CUSTOM/STANDARD). И вот что я обнаружил.

(Компилятор-в-песочницу - напомню, это тот же СР2, только он позволяет явно указать, откуда брать первоисточники и символьные данные, и куда складывать артефакты. Поскольку в проекте Тайлер я то и дело правлю основные модули, типа оконной подсистемы, - "чиню стул, на котором сижу" - мне очень неудобно пользоваться обычным СР2, потому что "стул" то и дело валится. Вот я и чиню, получается, соседний стул - компилирую "в песочницу" и из нее потом запускаю ББ)


Оказалось, что спецификация файла для чтения и для записи - разные вещи. Например, если компилятор хочет прочитать символьнй файл модуля М, то он вызовет GetSpec, и тот вернет ему локатор, указывающий на существующий файл - скажем, на этаже STANDARD. Затем компилятор решит, что нужно создать новый символьный файл для М. Однако тот же локатор, который возвращает GetSpec, нельзя использовать - он ведь указывает в STANDARD.

Я попробовал сначала добавить процедуру GetWrSpec, которая должна всегда возвращать локатор для записи, т.е. в USE. Ее оказалось достаточно.
Но все-таки при этом интерфейсе библиотекарь не полностью распоряжается библиотечными файлами. Все из-за Files.File.Register: например, компилятор получил от GetWrSpec указание, где должен создаваться файл; он его создает, и потом регистрирует. А если это был временный, ненужный в дальнейшем файл? Тогда его не нужно бы регистрировать. Но компилятор-то об этом не знает!

Тогда для компилятора-в-песочницу я пошел еще дальше:

MODULE CrossLib;

TYPE
Librarian* = POINTER TO ABSTRACT RECORD (StdLib.Librarian) END;

PROCEDURE (l: Librarian) Old* (IN mod: ARRAY OF CHAR; what: INTEGER): Files.FIle, NEW, ABSTRACT;
PROCEDURE (l: Librarian) New* (IN mod: ARRAY OF CHAR; what: INTEGER): Files.File, NEW, ABSTRACT;
PROCEDURE (l: Librarian) Register* (f: Files.File; IN mod: ARRAY OF CHAR; what: INTEGER), NEW, ABSTRACT;

PROCEDURE (lib: Librarian) Close* (f: Files.File), NEW, ABSTRACT;
(** Компилятор вызывает, когда "попользовался" старым символьным файлом *)

PROCEDURE (lib: Librarian) Drop* (f: Files.File), NEW, ABSTRACT;
(** Компилятор вызывает, когда компиляция не удалась, чтобы удалить (незарегистрированные) кодовый и символьный файлы; или когда новый символьный файл не отличается от старого *)

И в компиляторе-в-песочницу заменил GetSpec на Old, New и Register. Теперь вся логика работы компилятора с файлами вынесена в библиотекаря, и он как угодно может файлами жонглировать.

Такой ход позволил мне сделать спецбиблиотекаря, который позволяет запускать компилятор-в-песочницу "вхолостую": т.е. артефакты создаются, но не регистрируются (и после сборки мусора автоматически пропадают). Это нужно для проверки полноты и согласованности списков компиляции: возможно ли откомпилировать <список модулей> на базе папки <STANDARD>? Ранее для проверки полноты и согласованности мне приходилось делать выкопировку <списка модулей> в новую папку, запускать в ней ББ и там запускать компиляцию. Теперь эта рутинная задача решается автоматически, и мой рабочий процесс ускорился. Также, я экспериментирую про пакетный менеджер (коробейник, выходит, раз у нас BlackBox), и там тоже оч полезно компилировать в песочницу и филигранно управлять файлами.

Итог:
Предлагаю включить компиляцию-в-песочницу прямо в СР2: благодаря изящной архитектуре СР2 изменения незначительные и касаются всего двух модулей: DevCPM и DevCompiler. Прилагаю архив с поправленными модулями.

В DevCompiler добавлены тж команды для топологической сортировки и компиляции списков модулей. Эти поправки - другим цветом. Я полагаю, они были бы полезны тоже, хотя это другой вопрос (трудоемко выпиливать обратно эти поправки из моих личных модулей).

Вложения:
Sandbox.zip [33.15 КБ]
Скачиваний: 21

Автор:  adimetrius [ Вторник, 11 Май, 2021 16:25 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Кажется, тема не очень актуальна ))

Но для полноты: Иван Денисов справедливо отметил, что непонятно, что делать с содержимым архива. Уточняю:
1) Во-первых, смотреть: на те изменения, которые предложены в DevCPM и DevCompiler
2) А чтобы испробовать компиляцию в песочницу, я дошлю еще командный модуль, чтобы было удобнее пробовать.

Автор:  Иван Денисов [ Среда, 12 Май, 2021 05:31 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Утренняя мысль. А не кажется ли вам, что получилась что-то близкое к альтернативной реализация для Files? Зачем тогда называть это новой сущностью "библиотекарь"? Может сделать такой DevFiles, который будет устанавливаться перед компиляцией, и потом возвращаться обычный назад?

Автор:  adimetrius [ Среда, 12 Май, 2021 12:07 ]
Заголовок сообщения:  Re: #046 Библиотекарь модулей

Да, сходство есть, соглашусь; как в интерфейсе, так и в реализации. Но все-таки библиотекарь в DevLib - это не совсем каталог файлов. Это отделенная логика работы компилятора с модульными ипостасями.

Страница 4 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/