OberonCore

Я взялся за доработку подсистемы CDev (из сборки bb-revival-nix-0.1.tar.gz), задавшись целью создать компилятор КП для командной строки.
Компилятор состоит из "движка" (back-end) в виде доработанного модуля CDevCompiler, скомпонованного в cdev.dll, а также головной программы (front-end), написанной на Free Pascal (cpcc[.exe]).
На данный момент компилятор умеет только компилировать, создавая ocf и osf в директориях Code, Sym соответствующих подсистем. Отсутствует (пока) сборка в исполняемые файлы целевой ОС. Имея DevElflinker, уже можно двигаться в направлении Linux.
Итого, файлы планируется запускать с помощью загрузчика, использующего каркас в libBB[.dll/.so].
Последние новости читайте в сообщениях ниже этого.

исходные файлы.
Бинарник для Win32. Внутри находится также простой пример исходного кода вместе с файлом проекта. Всё распаковать в системный корень БлэкБокса. Наличие blackbox[.exe] не обязательно для работы, а только набор подсистем для компиляции и сборки.

Файлы обновлёны. Версия 2010-04-16 с "движком" компилятора версии 1.1.3

Выкладываю front-end, написанный на Free Pascal (cpcc [PE/Elf]). Возможно, его стоит написать в XDS. Сам CDevCompiler работает так, что сам ничего и никуда не выводит, а только хранит состояние компиляции, необходимой для считывания front-end'ом (то есть, номер ошибки, размер кода генерации и прочее).

Для компиляции используется fpcmake. Читать INSTALLATION в директории doc.
Модули для межплатформенной загрузки динамических библиотек, необходимые для компиляции cpcc. Распаковать в корневую папку исходников cpcc.

Файлы обновлены.

Застрял пока на одном месте: при ошибке в компиляции выводится номер позиции каретки в исходном файле и я не знаю как его транслировать в номер строки и столбца (для дальнейшего толкования внешними инструментами, к примеру, в редакторах vim/SciTE). Компилировать можно, но находить ошибки по номеру каретки трудно, поэтому приходится действовать вслепую.

Обновил файлы подсистемы CDev и исходные коды front-end консольного компилятора CPCC.

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

Нужно ещё добавить компоновку в исполняемые файлы...

Наконец-то сумел избавить модуль ElfLinker от некоторых зависимостей: Dialog, TextMappers, StdLog, DevCommanders. Я разделил его на две части, вынеся всё, что касается конкретно среды Блэкбокса в отдельный модуль CDevBuilder. А это обработка командера, всяких передаваемых параметров и подготовка списка модулей, надлежащих компиляции.

CDevBuilder.LinkDll libtestbb.so := TestExport# ~

Таким образом,

1. компоновщик ElfLinker занимается компоновкой и ничем больше. Он получает список модулей и связывает их в библиотеку / исполняемый код;
2. проще писать новые компоновщики, так как упрощена база.

Вести с фронта. Добил таки связку front-end с компоновщиком.
Статус компилятора таков:

1. проектировался как межплатформенная программа: загрузка библитеки компилятора с помощью LoadLibrary(Win32)/libdl(Linux), а пока только платформа x86;
2. умеет компилировать модули в текстовых файлах, создавая ocf и osf;
3. умеет компоновать в exe/dll (пока без обработки ресурсов);
4. почти умеет компоновать в so (см. * ниже);
5. в командной строке передаётся единственный параметр - имя файла проекта, представляющий из себя файл типа ini с описанием параметров проекта;
6. выдаются сообщения об ошибках ввода/вывода, компиляции с позицией ошибки.

(*) Почти умеет компоновать в so, потому что выявились отличия в создаваемых библиотеках ElfLinker'ом. Как выяснилось, ElfLinker не экспортирует символы переменных, а только точки входа процедур - в отличие от Linker, исправно создающей DLL со всеми символами.

** Файлы обновлены.

Желающие могут пощупать бинарник под вин32.

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

Движение создаёт оптимизм.

Двигателем прогресса является желание создать межплатформенный компилятор КП, создающий исполняемый код на целевых ОС.
Целью я поставил создание библиотек, состоящих из скомпонованных модулей и возможность использования сторонних библиотек целевой ОС (Windows-dll, Linux-so). То есть это хорошо для случая, когда необходимо создать независимый от BlackBox проект, выполняющийся обычным способом (exe/dll/so).

Касательно компилятора хочу посоветоваться.
Я решил отталкиваться от поставки BB 1.6RC5, поэтому к вам вопрос: устанавливать ли компилятор в корень дистрибутива ББ (необходим для компоновки модулей ББ) или же в отдельную директорию, создавая профиль с необходимой информацией о том где корень ББ, где лежит cdev.[dll/so] (а тут возможны подводные камни) ?

При этом остаётся возможность применения каркаса ББ с его динамически подгружаемыми модулями (ocf), если исключать этап компоновки в исполняемый код. Таким образом, возможно динамически загружать программу со всеми компонентами, используя libBlackBox (который ещё сырой). Этот вариант, пожалуй, стоит развивать. Однако, каркас прочно основавается на GUI, а с его портированием есть немало проблем. Тогда вырисовывается другой вариант: создание не-GUI каркаса, предоставляющего собой самый настоящий framework наподобие .NET (минимальный набор для динамической загрузки), тогда для пользовательского интерфейса останется поднапрячься с портированием HostWindows и прочих.

Пример файла проекта TestExport.prj:


Запускать в корневой директории BB


Если всё успешно, то на выходе получим export.dll.


Если есть ошибка в коде, то типа этого:

Новости
Наконец-то получился рабочий вариант компилятора для ОС Linux, создающий библиотеки .so! Так что межОСность уже присутствует.

Ув. коллеги! Теперь можно писать компоненты, использующие сторонние библиотеки GNU/Linux.

Итак,
Linux: libcdev.so + cpcc + [корень подсистемы BlackBox]
Windows: cdev.dll + cpcc.exe + [корень подсистемы BlackBox]

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

Файлы выложу позже.

P.S.
А этот компилятор, вообще, кому-то, кроме меня, интересен?

Есть штатный компилятор ББ и DevElfLinker, который делает библиотеки .so. Мне удобнее запускать оное хозяйство из-под wine; необходимости в консольном-исполняемом из-под Linux варианте пока не ощущаю.

Время быстро идет... Но авторам, жаждущим признания, всегда кажется, что медленно

Интересен, конечно.

Да.

Отлаживаю связку CDev с cpcc: пока не всё гладко работает; проверяю защиту "от дурака".

Спасибо за поддержку!

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

А этим опытом в нужный момент где-то с кем-то поделитесь.

Так что, и сомневаться нечего - польза большая.

Обновил файлы до версии 1.1.3 (см. сообщения № 1 и 2 в теме):

1. CDev - компиляция и сборка для OS Linux/Windows: .so/.dll .
2. cpcc - улучшена обработка ошибок и дружелюбность к пользователю. Хотя сам факт наличия ошибок не отрицается.

Это функционально эквивалентно какому-нибудь gcc?
Из ЦЕРНа жалуются на состояние дел -- может, стоит туда дать информацию про этот компилятор?

Похож на fpc/gcc в традиционном понимании компиляции.
Можно дать ссылку на страницу моего домашнего сайта: http://romiras.dyndns.org/doku/bbox/com ... l_compiler . Частично перевёл на английский. Дома постараюсь дописать полную документацию на английском.
Там же и бинарные сборки для Linux/Windows.

Планирую также написать межплаформенный компонент для динамической загрузки модулей, по подобию Dialog.Call, но без Блэкбокса.