OberonCore

возникает вопрос - а какой собственно каталог является рабочим? ну, куда компилять и сохранять?

Как и в случае /USE, крайний.

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

Здесь есть проблема. Не должно быть разных версий одного и того же модуля. Поэтому если будет изменен модуль из стандартного ББ то библиотека должна будет брать именно его (из рабочего каталога). Да, есть опасение, что проблем может быть больше чем пользы.

Вообще мне такой промежуточный /USE2 давно хочется.
Есть base, над ним разные сборки (школьная, ун-ская, рабочая). И рабочие папки.

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

Можно уточнить, о каких проблемах тут речь? Примерчик.

Нет, примерчиков нет, просто опасение.

Ну хоть сценарий, хоть намёк какой, хоть что-то в плане мозгового штурма (когда по голове за идею не бьют).

Откуда-то же опасение возникло?

Ну в общем от не знания механизма обеспечения загрузки актуальных версий модулей при серверной установке. Не возникнет накладок при появлении "третьего"? Допустим для своих нужд мы изменили какой-то модуль из стандартного ББ. Наш проект в наших руках, а библиотеки?. А если библиотека без исходников?
Впрочем (при сохранении все в /use) эта ситуация не зависит от наличия отдельного каталога для библиотек. Это у меня наложилось.
Кстати в Делфи такая ситуация у меня случалась, подцеплялся модуль из другого каталога (такой же, но не совсем) и правильно компилился гад ...

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

Вот если бы можно было библиотеки как-то параллельно соединять, тогда да-а-а...

Посмотрел внимательно на HostFiles на предмет работы с ключом /USE.

Логика /USE проста, как чурбан и опирается на понятие стартапа (это локатор, указывающий на путь /USE) и теневой директории (это папка, где лежит BlackBox.exe):

1) dir.This использует стартап /USE
2) dir.Old использует теневую директорию, если файл не найден в локаторе.
3) Теневая директория используется для двухпроходного получения списка файлов и локаторов. Первый проход делается в локаторе, второй в теневой директории.

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

Например, мы имеем три папки:

1) BlackBox (ядро ББ, скачанное с oberon.ch)
2) BBCC (коллекция компонентов из хранилища oberoncore)
3) Work (мои компоненты и проекты)

Пусть Work - это стартап, а BlackBox и BBCC - теневые папки. Тогда если вы являетесь автором компонента BBCC, и решили исправить замеченную ошибку, тогда ваш исходник сохранится в папку Work. Вам придётся вручную переносить его в BBCC и делать коммит. Неудобно!

P.S. Другими словами, как только у нас уровней более двух, как сразу же возникает головная боль (у пользователя) с разруливанием целей для операций записи.

Первой в голову приходит идея режима, при котором каталоги виртуально объединяются для чтения, но запись происходит обычным образом, в соответствующий физический каталог, то есть, присоединили work и bbcb, и компоненты из work компилируются в него же.

Вторая идея, это составлять список каталогов для объединения в режиме "только чтение", а для записи требовать от пользователя отдельный каталог, при этом он может совпадать с одним из каталогов из списка объединения, это остаётся на усмотрение пользователя.

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

Ну а следующие идеи можно составить из взаимосочетания двух предыдущих.

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

При наличии симлинков проблема синхронизации отпадает. Винда ведь позволяет симлинки на папки.

Это не отменяет проблемы наличия исходника модуля в двух разных местах

Что-то я не понял в чём всё-таки проблема, когда тот же исходник доступен в двух папках одновременно.

Как только выполнено исправление ошибки в BBCC, делаешь коммит...?! Где здесь конфликт или неудобство?

Не удобно. Вы не первый, кто столкнулся с этой проблемой. Конкретное решение организационного плана давно работает: viewtopic.php?p=70771#p70771 и пример в конце заметки.

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

Могу рассказать как я организовал разработку под AOS может это окажется полезым ЧЯ собратьям viewtopic.php?f=22&t=4292

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

В общем, я переделал HostFiles для поддержки двух теневых папок. Теперь ядро ББ в одной тени, опенсурс-комплект во второй тени, а проекты в стартапе. А если мне надо поработать над опенсурсом, есть второй ярлычок, где опенсурс-комплект подключается обычным образом, через /USE.

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

Ещё один вариант решения, со своей спецификой, под конкретные нужды. Пример широкой применимости ББ за счёт лёгкой изменчивости.

P.S. Если делать спец. реализацию-обёртку Files вместо переделывания HostFiles, то решение будет компонентным.

Проблема решается ссылками на каталоги, а не ссылками на файлы.

Я всё равно не врубаюсь, как симлинка на папку не даст записать исходник ядра (например) во вторичную папку-стартап. Привожу мою схему без использования симлинков