После перехода с Дельфи и по мере освоения Лазаруса начинаешь понимать, что среды все-таки довольно сильно отличаются друг от друга. Это отличие особенно заметно, если писать кроссплатформенное приложение. И проявляется оно тем, что для разных ОСей одни и те же функции и константы описаны в разных модулях.
Чтобы все время не рыться в исходниках, решил положить для себя несколько напоминалок здесь, на виду.
1. Функции и константы
2. Потоки в Линукс
3. Автоинкрементация номера сборки
4. Макросы среды
5. Особенности символов переноса строки
6. Функции хэширования
7. Папка с настройками
8. Вывод исполняемого файла в отдельную папку
9. Некоторые директивы компиляции
1. Функции и константы.
Модуль для Linux |
|
Модуль для Windows |
|
Функция или константа |
LCLIntf |
|
JwaWinUser |
|
GetKeyState |
LCLType |
|
LCLType |
|
Virtual key code |
LMessages |
|
Windows |
|
WM_USER/SendMessage |
Обычно модули добавляются после Uses раздела Interface так:
{$IFDEF UNIX}
, LCLIntf //GetKeyState for LINUX
, LCLType //virtual key code for LINUX
, LMessages //WM_USER for LINUX
{$ELSE}
, JwaWinUser//GetAsyncKeyState of WINDOWS
, windows //WM_USER for WINDOWS
{$ENDIF}
2. Потоки в Linux.
При использовании потоков компилирующийся и работающий на винде проект, в Линуксе вдруг валится с ошибкой. Проблему должно решить следующее: в файл проекта в разделе uses необходимо добавить следующий код:
uses
{$IFDEF UNIX}
cthreads, cmem,
{$ENDIF}
Interfaces, // this includes the LCL widgetset
<skiped>;
{$R *.res}
3. Автоинкрементация номера сборки
При выставлении в настройках проекта опции "Автоматически наращивать номер сборки"
фишка будет работать только в том случае, если компилировать проект <Shift + F9> (вместо привычных по Дельфям <Ctrl +F9> или просто F9)
4. Макросы среды
Вещь нужная и полезная, когда не хочется вручную прописывать различные параметры при компиляции, сборках и экспорте данных. Статья на русском тут
5. Особенности символов перевода строки
Когда я импортировал проект, успешно запускающийся под отладчиком в Lazarus на винде, в Lazarus на линуксе, то при попытке запуска получил вот такое "веселое" окошко

с предупреждением: "The GDB command: "-gdb-set confirm off" did not return any result."
Проблема оказалась в следующем: в редакторе кода исходник, написанный в винде, имел "виндовое" окончание строк. После исправления этого "недоразумения" (ПКМ --> Параметры файла --> Конец строки)

отладчик успокоился и спокойно запустил скомпилированное приложение.
Update: начиная с версии lazarus 1.7 такой ошибки в Линуксе больше нет, несмотря на разную кодировку конца строки. Для Windows ошибка сохраняется, если указана кодировка не CRLF.
6. Функции хэширования.
Оказывается в FPC уже есть готовые и удобные функции для получения хэша, которые находятся здесь ...\fpc\3.0.0\source\packages\hash\src\ в файлах md5.pp и sha1.pp
Для получения строки хэша необходимо написать свою обертку с использованием функций MDPrint и MDString/MDBuffer/MDFile (для MD5) или SHA1Print и SHA1String/SHA1Buffer/SHA1File (для SHA1).
Пример можно найти здесь.
7. Папка с настройками.
Иногда надо, чтобы IDE загружала свои настройки из произвольной папки. В таком случае необходимо в корневую папку с лазарусом положить файл lazarus.cfg со следующим содержанием
--primary-config-path=/<полный абсолютный путь к папке с настройками>/<папка с настройками>
Таким образом можно иметь на одной машине несколько версий среды, каждая из которых будет иметь свой каталог настроек.
8. Вывод исполняемого файла в отдельную папку
Поскольку в Лазарусе есть возможность создания исполняемого файла как с отладочной информацией (режим Debug, или Default), так и без нее (Режим Release), то возникает потребность, чтобы эти файлы "складывались" в "свои" отдельные папки. Для этого следует сделать следующее:
1. Создаем новый проект, сохраняем его куда-нибудь на диск, затем открываем опции проекта Project --> Project Options (<Ctrl>+<Shift>+<F11>) и переходим на вкладку Compiler Options --> Paths

2. Помечаем сначала чекбокс "Build modes" (1), а затем кнопку с троеточием (2)

3. В открывшемся окне жмем кнопку "Create Debug and Release modes"

4. Затем удаляем режим "Debug", ставим галку "Active" напротив строки с режимом "Default" и сохраняем настройки

5. Теперь выбираем режим "Default" и в строке "Target file name" вводим Debug\$NameOnly($(ProjFile))

6. То же самое проделываем для режима "Release", только вводим Release\$NameOnly($(ProjFile))

7. Сохраняем настройки проекта и поочередно компилируем проект в каждом режиме.

Указанные папки автоматически создадутся в корневом каталоге проекта.

Как видно из их размера, один из файлов содержит отладочную информацию, а другой нет


9. Некоторые директивы компиляции
1. Выше уже говорилось о двух режимах компиляции проекта: debug и release. Чтобы разделить режим сборки в коде, можно использовать директиву компилятора {$IFOPT D+}
{$IFOPT D+}
//код для режима сборки debug
{$ELSE}
//код для режима сборки release
{$ENDIF}
|