OberonCore

Как известно, ББ имеет вариант т.н. "серверной" инсталляции (см. System\Docu\User-Man). Этот вариант относится к одной маленькой проблеме, проблеме "зачистки" комплекта ББ от лишнего кода, возникающего при работе нескольких программистов с одним комплектом ББ. Эту проблему предлагается решать размещением "главного" комплекта на сервере в локальной сети и созданием на рабочих местах локальных "пользовательских профилей", обращающихся к серверной установке с помощью ключа /Use.

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

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

Итак, мы имеем крайне сжатое техническое решение (работа с одним профилем), в которое все заинтересованные лица пытаются втиснуть свои чемоданы, как например:
viewtopic.php?p=70771#p70771
viewtopic.php?p=78812#p78812

Предлагаю как-то поговорить об этом. Я не представляю пока, какая идеология сможет заменить базовое решение с одним профилем. Но может, искра идеи промелькнёт?

а что, /Use не принимает список каталогов?

Список каталогов расширяет идею одного пользовательского профиля до нескольких одновременно используемых профилей, что не меняет идею в целом. Те же яйца, только сбоку, плюс усложнение работы до уровня полного непонимания где лежат исходные модули, а где изменённые. Сам по себе ключ /Use не понимает списка каталогов. Я сделал дополнительный "теневой" каталог, позволяющий работать не с одним профилем, а с двумя (ключ /SHADOW), но ничего блестящего в этой идее нет.

Если рассмотреть фичу /USE в плане реализации, то она не то что несовместима с текущими реалиями работы человеков над подсистемой, а прямо противоречит ей. Одна песочница на человека. Никакой обратной связи и изменения серверной части файлов в режиме запуска с ключом /USE сама система ББ не поддерживает. То есть, ключ /USE реализует антисовместную разработку.

Было бы странно, если бы система ББ поддерживала для ключа /USE то, о чём Вы гововрите, Пётр. Потому что задача для него ставилась ровно противоположная, она соответственно реализована и работает как положено. См. "BlackBox Component Builder User Manual, 4 Server installation (Windows only)".

P.S. Моё замечание не ставит целью оспаривать соображения о специфике способов работы и соответствия им ББ как инструмента, и необходимость его адаптации в случае не соответствия...

Согласен с Иваном К., хотелось бы иметь возможность трехслойной разработки.

1. Блэкбокс
2. Сторонние компоненты (несколько разных конфигураций)
3. Проект

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

В XDS для указания, откуда чего брать используется файл .red, где указываются пути. Может сделать поддержку подобных файлов для BB? Например, если в папке профиля лежит файл Layer.odc в котором указан путь к папке со сторонними компонентами, то они автоматически подцепляются как будто находятся в родительской папке ББ.

Никто ключ /USE не критикует, для тех задач для которых он был задуман он чудесен, но для этой задачи он используется как костыль.

Иван, ты сказал про XDS-овский .red, и я вспомнил, что у меня в Кларионе такой же файл был, с редиректом для разных категорий файлов, такого содержания:



Для ББ попроще будет, у нас же готовый набор соглашений по структуре папок в подсистемах. Вот только как быть с тем, что ББ читает из нескольких, а пишет в один каталог? Может, отказаться от этой схемы и сделать очевидную "откуда прочитал, туда же и записал"? А возможные пересечения подсистем (например, подсистема Host лежит в базовой сборке и в вашем репозитории) рубить на корню, при загрузке (это идея Петра).

По умолчанию, ИМХО, лучше как сейчас — меняется только последний каталог, вся запись в него. При необходимости доработки используемых компонентов безопаснее открыть другой ББ и там выполнить изменения (я так делаю сейчас).

Это конфиг-файл компилятора со списком путей или конфиг-файл проекта со списком источников модулей?

То, что привёл я - файл .red с путями по умолчанию. Такой же файл можно положить в папку проекта и его пути перекроют умолчальные.

Такое решение позволит гибко настраивать условия работы над проектом, но для этого придётся ввести в ББ сущность проекта (слоя, среза).

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

Если вспомнить, что в ББ уже есть договорённость про подсистемы, которые представлены Локатором с определённым именем в корневом каталоге ББ. Этот каталог тоже интересный объект для исследования.

Сейчас, как мне кажется, основная проблема в том, что файловая подсистема предоставляет недостаточно виртуальный корневой каталог, он в реализации опирается сразу на файловую систему компьютера, а потом даёт нам возможность слегка себя отрегулировать (через /USE).

А так как файловые системы нижележащих ОС могут иметь сколь угодно сложную организацию, хост файловой системы сразу начинает отвечать за две в общем разные задачи - навигация внутри каталога ББ (простые правила, определены договорённостями) и навигация во внешней ФС (все уже импортировали HostFiles ради полного системного пути и теперь должны страдать ). А ведь есть ещё симлинки со своей природой, которые вообще никак не представлены в абстракциях ББ.

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

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

Я всегда думал, а почему в ББ до сих пор нельзя работать с StdCoded текстами как с виртуальными каталогами (прямо с сайта цинна, хы). А ведь есть ещё облака.

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

https://bitbucket.org/petryxa/priv/src/ ... at=default

Чтобы заработало надо создать тестовый каталог и наполнить его всяким

Это пока не реализовано, но пока я выделяю два способа подключения сторонних каталогов - слияние в режиме SHADOW (хорошее слово), и подключение "каталог в каталог", в режиме например MOUNT.

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

Ну, всё-таки, в ББ понятие проекта всё-таки есть, с самого начала: проекты представлены подсистемами.

Но это действительно другая идеология.

"Проект" очень популярный и известный образ. Собираем воедино кучу исходников и ресурсов, увязываем их со сторонними компонентами, а потом эту кучу скармливаем комбайну-IDE. Комбайн выдаёт нам "продукт", который можно забрать с собой и который может жить отдельно от комбайна. Под этим углом зрения постоянно пытаются рассматривать BlackBox Framework, что в корне неверно и приводит ко всяким естественным для такого подхода вопросам типа "как сделать .exe".

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

Монолитизация, в каком-то смысле.

Возвращаясь к практической части, cегодня допинал некоторые нюансы, и успешно (почти) собрал все подсистемы bb.open с использованием bbcc-svn, при этом ни разу не скопировав, не создав симлинк и даже обошёлся без запуска с параметром /USE. И это всё на чистой сборке ББ-core

https://bitbucket.org/petryxa/priv/comm ... Mod/FS.odc
Нерешённых проблем несколько.
Непонятно, как быть с дублированием модулей и компонентов, на основании чего выбирать ту или иную версию, нужны приоритеты, наверное.
Сейчас запись и чтение производятся строго в shadow локаторы, при этом, нужно такое поведение регулировать, перенаправлять запись и прочее.
Все сторонние подсистемы, которые опирались на HostFiles.Locator превратились в тыкву из-за смены типа локатора. Например, HostWindows перестала выводить имя подсистемы в скобочках перед именем модуля.
Но если не рассматривать данное решение как боевое, то прототип получился вполне показательный. Например, он показывает, что исходный код компонента должен быть в единственном подконтрольном экземпляре, а иначе получается дублирование, наложение разных версий и муки выбора (автоматически нерешаемые, как я понимаю).
Такой вот результат.
P.S. Импортировать хосты - неправильно, да.

Для "каталог в каталог" достаточно создать пустую директорию и SHADOW в неё. Тогда MOUNT и не понадобится.

А автоматически и не надо. Достаточно, чтобы SHADOW можно было использовать в запущенной среде.

В ОС Plan9 есть команда bind. Она занимается подобной работой.Эта команда приведёт к тому, что в dir2 будет видно содержимое dir1. Ключ -c обозначает разрешение создавать новые файлы. Ключ -b задаёт приоритет директорий (b - before, a - after), этот ключ нужен при совпадении имён файлов или создании нового файла. Отменить bind можно командой unmount.