search

AntKrotov / oberon-07-compiler

Oberon-07 compiler for x64 (Windows, Linux), x86 (Windows, Linux, KolibriOS), MSP430x{1,2}xx, STM32 Cortex-M3
BSD 2-Clause "Simplified" License
61 stars 5 forks source link

Ошибка компиляции под Linux #16

Closed prospero78 closed 3 years ago

prospero78 commented 3 years ago 
walera@walera-lin:~/coding/gowork/src/github.com/prospero78/obGraph$ SelfLinux64.sh
Compiler
index out of range
module: HOST
line: 83
/home/walera/bin/SelfLinux64.sh: строка 2: @pause: команда не найдена
prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

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

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] не раскрывает относительный путь в полный. Антон, просьба к тебе: сделал бы ты возможность распихивать модули по пакетам (аля директории). Неудобно же, когда масса файлов в куче лежит.

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

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

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

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

Ещё проще:

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

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

IMPORT mSqr := graph_square;

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

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

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

AntKrotov commented 3 years ago

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

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

Compiler index out of range module: HOST line: 83

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago 
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

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

AntKrotov commented 3 years ago

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

AntKrotov commented 3 years ago

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

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

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

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

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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

prospero78 commented 3 years ago

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

prospero78 commented 3 years ago

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

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

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

AntKrotov commented 3 years ago

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

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

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

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

prospero78 commented 3 years ago

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

AntKrotov commented 3 years ago

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