OberonCore

Раз вопрос вызвал интерес, открою всё же отдельную тему.

ДАвайте, для начала выясним, это кому-нибудь реально нужно? Или закончится на этапе обсуждения идей. Я своё мнение скромно высказал уже - даже убогий поиск по определению - это лучше, чем ничего. Т.е. без перехода к определению система полностью неконкурентоспособна и производительность труда в ней неоправданно занижена. Таким образом, если я буду заниматься bluebottle, то у меня это точно будет в каком-то виде. Трудности примерно ясны. Если есть смысл обсуждать решение, то давайте обсудим.

ДАвайте для начала признаем следующий неприятный файт: любая система с условной компиляцией, как бы она не была оформлена, это уже не одна система, а семейство из множества систем с пересекающимися исходными текстами. Ни запретом #ifdef-ов, ни созданием IDE от этой проблемы укрыться не удастся. Причём, если есть N платформ и всего лишь один переключатель отладка-производство, то это уже 2N систем. Если к тому есть один #define типа байт, то это уже 512N систем.

Если тут консенсус, то можно двигаться дальше и подумать, что из этого следует и как лучше поступить с этим.

В байте 8 бит, поэтому 256, а не 512.

А так да, переход к определениям, поиск всех использований (как в Visual Studio find all references), показ количества использований (если 0, то значит код мертвый, нигде не используется) были бы полезны.

Вы думаете, я не знаю, сколько бит в байте? N*2*256=512N.
В общем, пока не видно массы желающих обсудить вопрос. Тогда тезисно. Могут быть разные задачи при работе с многоплатформенным кодом:

• посмотреть, какой именно код собрался. Для этого лучше всего запись исходного пути с контрольной суммой в объектный файл
• ходить отладчиком. То же
• изучать код конкретно для этой платформы (например, понять или отладить его)
• изучать код как целое, с учётом всех платформ. В этом случае нужно на самом деле составить набор всех поддерживаемых сочетаний флагов (конфигураций, если в терминах MS Visual Studio). Чтобы поддерживать не 512N разных систем, а всего, скажем, 25. В этом режиме переход к определению должен показывать все поддерживаемые варианты, т.е. выдавать двухколоночную таблицу типа такой:
  
  Код:
  конфигурация    | место определения
  ----------------+---------------------
  windows,отладка | windows.mod, строка 7
  linux,отладка   | linux.mod, строка 21
  windows,промышл | windows.mod, строка 7
  linux,промышл   | linux.mod, строка 210
  
  
  Это можно решить без компиляции с помощью парсеров исходных текстов. Другое дело, что я нигде не видел такой подход реализованным, хотя он является единственно правильным. Именно к этой не весьма тривиальной мысли я хотел подвести сообщество путём обсуждения, но похоже, что это неразумно трудоёмко. Поэтому приходится писать явно.

В общем, быстрогрязное решение состоит в том, чтобы завести файлы конфигурации под каждую сборку, и в этих файлах указывать соответствие между именами модулей и именами файлов. Т.е. тупо перечислить каждый модуль и имя файла, в котором он определён. В файлах должна быть директива #include, которая позволит составить единый список всех платформо-независимых файлов. На этом фундаменте можно построить и «поиск по конкретной конфигурации», и «поиск по всем конфигурациям». Недостаток по сравнению с хранением инфы в объектых файлах состоит в том, что нет гарантии, что исходники вообще соответствуют сборке - это даже уязвимость. Т.е. решение достаточно компромиссное по качеству, однако, оно в целом (на мой взгляд), является шагом в правильном направлении. Следующие шаги могут быть такие:

- генерировать такой индекс по правилам, например, «всё, что начинается с «Windows.» - это про
windows и поместить в файл windows.карта-модулей».
- дублировать инфу и в объектном файле - сопоставляя инфу в карте модулей и в объектных файлах, можно будет определить некоторые ошибки devops.

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

Я ведь уже говорил - посмотри сначала файлы Release.Tool и Release.Mod

Видимо, не заметил этой подсказки. Можно ли поменять эти файлы так, чтобы список соответствий модуль-файл получался в качестве побочного эффекта для данного процесса сборки? P.S. но давайте не будем путать цель (что именно нам надо сделать) и средства (как этого добиться)

Там есть команды
Release.RequiredModules
Release.WhoImports
От которых можно оттолкнуться.
И есть ещё модуль ReleaseVisualizer.Mod который тоже стоит посмотреть

Спасибо, посмотрю.

В общем, я человек довольно косный. В файл Release.Tool посмотрел и даже нашёл там команды, как собирать. Что делает Release.Mod, не осилил - много букв. Т.е. примерно понял, что он парсит какой-то файл описания модуля и, видимо, делает что-то ещё, но дальше не полез.
Зато мне понравились текстовые символьные файлы.
Соответственно, я предлагаю (вслед за Сергеем Оборотовым) следующее:

• вводится понятие «корневой директории» - это директория, где развёрнута A2OS
• при компиляции в символьный файл записывается информация об исходнике, например, имя файла относительно корневой директории и хеш-сумма. Для этого можно расширить синтаксис, например, приделать в {} что-нибудь к слову MODULE.
• вводится понятие «директория символьных файлов для перехода к определению», по умолчанию равна просто директории символьных файлов.
• по команде «перейти к определению» мы ищем имя модуля, открываем символьный файл,
  считываем из него имя файла с исходным текстом, открываем файл в PET, рисуем дерево и
  показываем нужный узел.

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

Release.Mod работает с файлами, структура которых описана в Release.Tool. Release.Tool определяет некие сущности ( bulds, packages ) и связи между ними. То ест структуру проекта. На основе этой информации команда Release.Build и собирает А2 ( ну или другой проект ). На основе этой же информации команды Release.RequiredModules и Release.WhoImports находят файлы ( именно файлы ) попадающие в указанную сборку (build), анализируя секцию импорта. Файлы модулей, которые импортирует некий модуль (от которых он зависит ) или наоборот, которые зависят от него.
Например, Release.Rebuild позволяет пересобрать проект, компилируя только необходимые файлы ( инкрементальная сборка ).
Допустим, у нас изменился файл WMTextView.Mod. После выполнения Release.Rebuild Win64 WMTextView.Mod у нас будет командный файл для компиляции, который содержит только зависимые от WMTextView.Mod файлы ( под Win64 ). В зависимости от опций автоматически выполнится или будет выведен в IDE.

Это плохая идея - нужно использовать инструментарий из Release.Mod, возможно допилив и расширив функционал. Просто нужно в IDE парсить файл проекта ( который находится в файлах типа Release.Tool ) и использовать уже готовую инфу. Сейчас же это файл парсится при каждом обращении к командам. Ну или кешировать разобранную структуру.

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

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

Нужно менять и средства разработки - не должно быть "просто файлов", всё должно жить в структуре проекта, должно быть "решение" и в нём "проекты", как в Visual Studio. Это серьёзное изменение и серьёзные ограничения.

Мой подход, как мне кажется, таким ограничением не связан.

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

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

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

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

Можно сделать экспортированную константу с предопределённым именем, которую компилятор будет генерировать в каждом модуле, и которая будет содержать данные об исходнике. Тогда мы абстрагируемся от структуры символьного файла, а нам нужен только API доступа к нему.

А он там присутствует? Это вообще-то полная переделка структуры IDE, и ещё надо подумать, как лучше организовать. Кроме того, в этом случае файл Release.Tool начинает очень интенсивно (и автоматически) меняться и нужно разбивать на много файлов (как сделано в Visual Studio - отдельно файл решения и файлы проектов, в файле решения - конфигурации; в A2OS всё это есть по отдельности, но в довольно корявой форме, поскольку всё засунуто в один огромный файл).

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

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

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

Всё-таки лучше не плохое решение, а хорошее. Что такое "хорошее", конечно субъективно. Но пакеты, всё-таки, как мне кажется, существенно лучшее решение. К тому-же, нужно учитывать, что там, таки не только Оберон, но и Шарпоподобная поделка, ну и ещё много чего в паблике отсутствующего, не уверен, что везде будут одинаковые символьные файлы.
Ну вообще, какое-то решение там было, с менеджером проекта, но в паблике я не вижу.

Ну, лучше ездить на Мерседесе, чем на Запорожце, но на Мерседесе почему-то ездят не все. Так и тут.

Лучше велосипед, во всех отношениях - я за проекты/пакеты с зависимостями

Я тоже за, но ресурсы у меня есть только на символьные файлы. И при этом вы невнимательно прочитали и недостаточно продумали последствия того, о чём я сказал. При подходе с проектом нужно выкинуть возможность компиляции модуля из произвольного текста и оставить только компиляцию файла с диска. При этом, только файла, вставленного в проект и находящегося в положенном месте. Потому что в вашем подходе (в отличие от моего) нет никакого инструмента, позволяющего отловить факт компиляции исходника не из положенного места. Это даже уязвимость, а не просто затуплённость рабочего инструмента. Плюс придётся сделать достаточно удобный менеджер проекта. Плюс разбить файл описания проектов на много мелких. Сделать отслеживание изменений в них. Да и кнопка "компилировать этот текст" по идее должна уйти - ведь в Visual Studio её нет (или хорошо спрятана - я не так много работаю в Visual Studio, и её ни разу не видел). Там есть только "компилировать Soultion" и "КОмпилировать проект". Solution - это вся система. Только после этого ваш подход станет логически завершённым и «хорошим». Если не сделать из этого хоть что-то одно, это будет кривой костыль, более кривой, чем мой вариант с символьными файлами. Подумайте ещё раз, это точно то, чего вы хотите добиться?

Как бы то ни было, я это делать не буду, ни в одно лицо, ни в коллективе Пока не упрусь в какой-то тупик с символьными файлами.