Ошибка компиляции под Linux about oberon-07-compiler HOT 30 CLOSED

Проблема решена:

1. локальным копированием всего компилятора себе в проект
2. Указанием путей относительно файла КОМПИЛЯТОРА.

from oberon-07-compiler.

Да, есть такая недоработка: относительный путь к главному модулю проекта задаётся относительно файла компилятора. Размещение папки lib также фиксировано относительно файла компилятора. Чтобы устранить этот недостаток, мне нужно чёткое описание того, как это должно работать "по-нормальному" с примерами.

from oberon-07-compiler.

Прям вот лог при компиляции:

walera@walera-lin:~/coding/gowork/src/github.com/prospero78/obGraph$ make run.app
Compiler "../src/Main.ob07" linux64exe -out "../bin/main"
Compiler
index out of range
module: HOST
line: 83
./bin/main
X connection to :0 broken (explicit kill or server shutdown).
make: *** [Makefile:3: run.app] Ошибка 1

Вот эта часть:

BEGIN
    GetArg(0, path);
    n := LENGTH(path) - 1;
    WHILE path[n] # slash DO
        DEC(n)
    END;
    path[n + 1] := 0X
END GetCurrentDirectory;

Я так подозреваю, что речь идёт о том, что path[n] не раскрывает относительный путь в полный.
Антон, просьба к тебе: сделал бы ты возможность распихивать модули по пакетам (аля директории). Неудобно же, когда масса файлов в куче лежит.

from oberon-07-compiler.

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

from oberon-07-compiler.

Чтобы не ломать совместимость с сообщением о языке -- предлагаю не делать, как подсистемы в БлекБоксе (всё-таки, когда много каталогов -- там начинается адъ), а сделать в комментариях опции компилятора. Что-то вроде такого:

(* $IMPORT square=./graph/square.ob07 *)
IMPORT square;

Кто желает прям полной совместимости -- пусть кладёт модули как положено.

from oberon-07-compiler.

Лучше, наверно, сделать нормально, а не "совместимо". В общем-то, уже только символ "_" в идентификаторах не совместим с сообщением о языке. Так что...
А если вот так?
IMPORT square IN "./graph/square.ob07";
И так проще сделать, к тому же.

from oberon-07-compiler.

Ещё проще:

IMPORT mSqr := "./graph/square.ob07";

Если пошла такая пьянка, то конечно -- кромсать сообщение не стоит. Но эта штука будет вполне логична и целесообразна. Опять же, это не отменяет старых условий и предотвращает компиляцию на заведомо несовместимой платформе и/или несовместимом компиляторе (classic style). Совместимость с другими компиляторами важна, если кому-то будет надо -- переделать импорт будет не сложно при такой необходимости. Что-то вроде будет:

IMPORT mSqr := graph_square;

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

Также сообщение разрешает уточнённое имя (но не для имени модуля, увы).

Хм... Только сейчас обратил внимание в сообщении на отсутствие требования для литер "только ASCII" или "latin-1". Литеры могут быть какие угодно. Это, прям воодушевляет))

from oberon-07-compiler.

IMPORT mSqr := "./graph/square.ob07";

Выглядит довольно хорошо, мне понравилось.
И, похоже, особых трудностей в реализации не будет.

from oberon-07-compiler.

А вообще, согласен. Не надо правила переутяжелять, соображения два:

• приведение пути к имени через подчёркивание будет неочевидно, т.е. ЭТО глазами будет видно;
• чем проще компилятор, тем лучше.

from oberon-07-compiler.

Я исправил работу с относительными путями (вроде бы). Проверяй.

from oberon-07-compiler.

Ага. Посмотрим))
Я тебя расстрою. Симптомы те же.

from oberon-07-compiler.

Не может быть то же самое
типа такого:

Compiler
index out of range
module: HOST
line: 83

Что пишет вообще?

from oberon-07-compiler.

Может я старый вариант использовал?.... Хм. Пока нет времени на проверку. Чтобы точно диагностировать, просьба Антон -- включай в вывод метку сборки и дату у компилятора.

from oberon-07-compiler.

Понял, буду добавлять дату в вывод. Хорошо, когда будет время, тогда и проверишь. Торопиться некуда.

from oberon-07-compiler.

walera@walera-lin:~/coding/gowork/src/github.com/prospero78/obGraph$ make run.app
Compiler "../src/Main.ob07" linux64exe -out "../bin/main"

Akron Oberon Compiler v1.43 (64-bit)
Copyright (c) 2018-2020, Anton Krotov
--------------------------------------------

file /home/walera/coding/gowork/src/github.com/prospero78/obGraph/lib/Linux64/RTL.ob07 not found
make: *** [Makefile:2: run.app] Ошибка 1

Хм... Похоже, ищет библиотеки в каталоге проекта.

from oberon-07-compiler.

Ладно, вечером посмотрю.

from oberon-07-compiler.

Работает. Я изменил Makefile из твоего репозитория на такой (указал относительный путь к новому компилятору):

run.app:
../oberon/Compiler "./src/Main.ob07" linux64exe -out "./bin/main"
./bin/main

Компилируется и запускается, только терминал пишет:

./Makefile1: строка 1: run.app:: команда не найдена

Но это не влияет на работу компилятора.

from oberon-07-compiler.

С явным указанием относительных путей работает. (* И с самого начала так работало *)
Я хотел запихнуть компиль с либами в /home/walera/bin и вызывать компилер без всяких путей:
Compiler "./src/Main.ob07" linux64exe -out "./bin/main"
И вот в таком варианте -- уже нет. Т.е. компилер не ищет либы относительно собственного положения.
А пихать компилер в каждый проект.... Ну, может с точки зрения сохранения целостности проекта это и решение, а с точки зрения таскания компилера и всех его кишок из проекта в проект -- не очень идея.

from oberon-07-compiler.

Раньше не так работало. Раньше, относительный путь к проекту задавался только относительно компилятора. Теперь -- относительно рабочего (текущего) каталога. Компилятор должен знать свое расположение, чтобы найти папку /lib/. Получает он эту информацию из нулевого параметра командной строки. Как еще передать ему собственное расположение -- я не знаю. Пока же, чтобы не таскать компилятор в каждый проект, можно попробовать положить в проект два системных модуля API и RTL для соответствующей ОС. Компилятор сначала ищет модули в папке проекта и только потом в /lib/. Правда, если потребуется скомпилировать проект для другой ОС, то придется заменить API и RTL в проекте. Или сделать универсальные API/RTL с применением условной компиляции.

from oberon-07-compiler.

Эмм... Есть же команда pwd, которая показывает текущий каталог. Вот результат pwd и подставлять перед обращением к lib.

from oberon-07-compiler.

Так и сделано, только текущий каталог # каталог компилятора.

from oberon-07-compiler.

Может, добавить экспорт переменной окружения для библиотек? И если её нет, выдавать предупреждение?

from oberon-07-compiler.

Над этим надо подумать. Еще не приходилось работать с переменными окружения.

from oberon-07-compiler.

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

from oberon-07-compiler.

Я сделал импорт с указанием пути. Только через "IN". Так оказалось проще.
IMPORT mod IN "./lib/module.ob07"
Слэш можно использовать любой: "/" или "\" -- без разницы. Тестировал на Windows, но на Linux тоже должно работать.
Путь задается относительно текущего модуля (или абсолютный).

from oberon-07-compiler.

Да, относительный импорт работает.

from oberon-07-compiler.

Хм. Что-то сломалось.

compiling (14) Main (SYSTEM)

  error  (66) (101:28) incompatible parameter
  file:  /home/walera/coding/gowork/src/github.com/prospero78/obGraph/src/Main.ob07
make: *** [Makefile:3: run.app] Ошибка 1

Вроде, ничего не изменилось. Но что-то сломалось. Код (в сущности) не менял. Глянь, что случилось? Я ошибок не вижу, параметры соответствуют, экспорт не менялся.

from oberon-07-compiler.

Чтобы работало, надо просто поставить расширение файлов модулей.

вместо
mSqr IN "./graph/square", mEvn IN "./graph/event";

так:
mSqr IN "./graph/square.ob07", mEvn IN "./graph/event.ob07";

Но поведение странное, надо разбираться.

from oberon-07-compiler.

Исправил везде расширения, собралось правильно. Чтобы поведение был правильное -- при импорте надо проверять принудительно расширение файлов.

from oberon-07-compiler.

Исправлено. Теперь, если расширение не указано, будет ошибка: "файл не найден".

from oberon-07-compiler.