Прошу не отчаиваться.
Сам был почти в таком же положении, щас будем разбираться.
Reobne писал(а):
Я простой писатель библиотек, и мне страшно разбираться, как работают BAT файлы. Я чувствую, что если начну думать о них, то забуду свои великие идеи, которые хочу реализовать в библиотеках.
Не боги горшки обжигают — бери и делай свой батник, притом не с нуля, а на основе готового из папочек Obj и Lib/Obj
Основная трудность батников — это как раз ключики командной строки SDCC. Знание о том, какая папка в батнике текущая, позволяет легко добавить в батник команды копирования.
Разберёмся как может быть устроен батник Bin/compile.bat, устраняющий необходимость копирования .h и .c файлов:
Код: "OBERON"
@CD ..
@IF EXIST %1.c GOTO c_lib
:o_lib_obj
..\Bin\sdcc Obj\%1.c -mz80 --opt-code-size --no-std-crt0 --disable-warning 59 --disable-warning 85 -I "." -I
include -I Obj -L z80 XDev.lib
@GOTO exit
c_lib:
..\Bin\sdcc %1.c -mz80 --opt-code-size --no-std-crt0 --disable-warning 59 --disable-warning 85 -I "." -I
include -I Obj -L z80 XDev.lib
exit:
@IF errorlevel 1 PAUSE
При его запуске (F11-компиляция) не следует обращать внимания на варнинги, поскольку полной сборки рабочего бинарника не осуществляется. Но варнинги такого вида:
Reobne писал(а):
Возникли предупреждения:
Код: "OBERON"
?ASlink-Warning-Undefined Global '_EsgoeTypes__init' referenced by module 'Esgoe_003'
происходят из-за того, что батник (в момент вызова SDCC) не знает ничего о библиотеке Esgoe.lib, и, соответственно, её нужно подключить простым добавлением Esgoe.lib в команду вызова SDCC.
Reobne писал(а):
Варнинги меня сильно смущают, и пугают, это как ругань, мне говорят что я делаю что-то неправильно, но что - я не могу понять. Каждый раз копировать файлы *.с и *.h я устал.
Внизу я прикреплю архив с собираемой библиотекой. Но замечу, что батники — самая гибкая система быстрого скриптования, и я не вижу как избавиться от них целиком или хотя бы частично, поэтому придётся разбираться понемножку. Я буду помогать, я же для этого специально и форум создал. Главное — не сдаваться.
Reobne писал(а):
Нужно сделать так, чтобы для простой библиотеки не нужно было каждый раз копировать файлы с и h, а только для продвинутых писателей, которые включат в оберон-код библиотеки особый ключ, например (*$C-Lib*)
Я тоже думал как бы это решить, но в итоге пришёл к выводу, что не следует такие вещи выносить в исходник. Скрипты сборки (мейк-файлы в терминологии Си) есть скрипты сборки, и даже стартовый адрес кода и данных — это низкоуровневые понятия.
Reobne писал(а):
Либо хотя-бы хорошо описать работу BAT-ников, только то, что нам нужно для работы в ZXDev. Что куда копируется и зачем. С примерами сборки:
библиотеки со смартлинковкой и редактированием Си кода;
библиотеки со смартлинковкой и без редактирования Си кода;
библиотеки без смартлинковкой и редактированием Си кода;
библиотеки без смартлинковкой и без редактирования Си кода.
Конечно поддерживаю!
Ты сейчас мне работку тоже задал. Тонкости они, брат, завсегда в любом деле есть, все заранее не учтёшь. Вот чего получилось:
Цитата:
h:\Archive\Projects\XDev\ZXDev\Obj>..\Bin\sdcc EsgoeTest.c -mz80 --code-loc 45056 --data-loc 63488 --no-std-crt0 --opt-code-size --funsigned-char --disable-warning 59 --disable-warning 85 -I "." -I ..\Lib -L ..\Lib/z80 Basic.lib XDev.lib Esgoe.lib
?ASlink-Warning-Undefined Global '_Basic_CLS' referenced by module 'Esgoe'
?ASlink-Warning-Undefined Global '_Asm__init' referenced by module 'Esgoe'
?ASlink-Warning-Undefined Global '_Basic__init' referenced by module 'Esgoe'
?ASlink-Warning-Undefined Global '_Basic_AT' referenced by module 'Esgoe'
?ASlink-Warning-Undefined Global '_Basic_PRSTR' referenced by module 'Esgoe'
Я разгадал проблему и такого рода варнингов. Смотри что получается. Из-за того, что при компиляции библиотеки Esgoe заголовки SDCC берёт не из Lib, а из Obj/Lib (а там пустышки, — сгенеренные Ofront'ом пустые тела), — получается, что при использовании скомпилированной таким образом библиотеки лезут варнинги. Нам необходимо поправить пути. И если знаешь чего происходит, уже ясно как с этим бороться. Первый блин комом, как водится.
Ещё может влиять порядок перечисления библиотек. Я меняю в строке вызова компилера:
-I "." -I include -I Obj
на:
-I include -I Obj -I "."
и это... не помогает! А ведь причина зарыта где-то здесь. Поэтому чешем тыкову и думаем дальше. Можно сперва скопировать из Lib/Obj в Lib, но упс — и так не получается. Вобщем, долго я провозился. И пришёл к выводу, что приоритет при инклюде одноимённых заголовков из разных папочек всегда в пользу даже не текущей папки, а папки, из которой берётся исходник, т.е. в нашем случае это папка Obj. Даже если её не указать в пути ключиком -I Obj. Что ж, может это и "скорее баг, чем фича" компилятора SDCC, но нам остаётся до лучшего решения использовать автокопирование. Правлю скрипт, чтобы копировал Lib/Obj/Esgoe.* в Obj/Esgoe.*, и дальше всё будет собираться накатанным способом.
Я раньше чисто обероновские библиотеки не создавал, может поэтому и не предусмотрел этот способ в скриптах.
Reobne писал(а):
Если с моноблочным загрузчиком больше проблем, то почему не сделать по умолчанию обычный загрузчик?
Сделаем. Просто руки не дошли.
Reobne писал(а):
И адреса блоков кода и данных, их тоже надо как-то сделать явными, больше про них написать, что-ли. Или внести в исходник (*$MAIN ZXCodeAddr:=50056 ZXDataAddr:=63488*) Хм, нет, исходник должен быть униплатформенным, некрасиво если он будет наполнен настройками каждой платформы.
Да, точно. Все эти вещи — в скрипт сборки. Ведь обычно кодер платформы знает особенности платформы.
P.S. Вся проблема вытекает не из Оберона, а из особенностей скрещивания Оберона и SDCC, но, видит бог, другого выхода задействовать Оберон в программировании для Спека я не нашёл.
Вход
FAQ
Поиск
