Лазарь, Какой Он Есть

Нередко наше нежелание разобраться в вопросе и уверенность в собственной логике порождают неверные предположения.

Эти предположения, выраженные в виде заявлений на публичном форуме, могут прочно поселиться в головах других людей и сформировать ложно-негативные идеи.

Так вот в комментариях к недавней теме «Вышел Lazarus 1.0!» Были сделаны некоторые неверные утверждения и задан ряд вопросов, оставшихся без ответа.

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

Заявление : Размер исполняемых файлов оставляет желать лучшего.

Виноват компилятор, компоновщик и т.д. Некоторую информацию по этой теме можно найти по адресу вики-страница .

Итак, основной составляющей размера исполняемого файла является отладочная информация.

Отладочная информация добавляется компилятором FPC, когда ему передается ключ «-g».

FPC может генерировать 2 типа отладочной информации: устаревшие стабы и современные dwarf (версии 2 или 3), которые также определяются переключателями, передаваемыми компилятору.

Оба типа отладочной информации понимаются отладчиком GDB. В Lazarus вы можете включить/отключить отладочную информацию, а также определить ее тип на вкладке «Макет» в параметрах проекта:

Лазарь, какой он есть

Если вы создаете проект под Windows или Linux, вы можете создать внешний файл символов отладки.

В этом случае в исполняемый файл не будет добавлена отладочная информация, а вместо нее будет размещена ссылка на внешний отладочный файл.

Исключение отладочной информации уменьшает размер проекта пустой формы с 20 МБ до 1,6 МБ в Windows. Но 1,6МБ — это тоже больше, чем 300Кб, которые выдавал Delphi 7 (Delphi XE, например, уже выдаёт существенно больше из-за разбухания RTTI).

Дело не в том, что компилятор или компоновщик правильно выполняют свою работу, а в LCL. LCL — библиотека компонентов Lazarus архитектурно состоит из двух частей: фронтенда — платформонезависимой библиотеки классов для разработчиков приложений (TForm, TButton, TLabel, .

) и бэкенда — части, отвечающей за реализацию этих компонентов для конкретной платформы ( win32, qt, gtk2, .

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

Например, следующий код из модуля lcl\interfaces\win32\win32proc.pp подтягивает в исполняемый файл классы TCustomGroupBox и TCustomTabControl, даже если вы их нигде не используете:

if (TheWinControl is TCustomGroupBox) then begin .

end else if TheWinControl is TCustomTabControl then begin .

end;

Рефакторинг может решить эту проблему, но он требует значительных усилий и времени, которые в условиях нехватки рабочих рук лучше потратить на решение других проблем.

Надо сказать, что определенные усилия в этом направлении были предприняты еще 2 или 3 года назад, что позволило уменьшить размер пустого проекта с формой на 300Кб.

Заявление : Я когда-то устанавливал Lazarus на Windows, и помню, что даже самая простая программа с окном и кнопкой очень долго компилируется.

Проблема возникла, когда FPC использовала компоновщик GNU для Windows. Но в FPC 2.2 (а Lazarus теперь использует FPC 2.6) проблема была устранена путем разработки встроенного компоновщика для Windows. Кроме того, в то время компоновщик GNU не умел компилироваться для платформы Win64, что также послужило толчком к разработке собственного встроенного компоновщика.

Следует отметить, что под Linux и Darwin таких проблем со скоростью сборки не было и нет (и как следствие, для этих платформ до сих пор нет нативного компоновщика).

Теперь сборка и запуск пустого проекта с формой на моей машине занимает не более 2 секунд. Вопрос : Было бы здорово, если бы в Lazarus появилась нормальная стыковка, как в Delphi 2006, например.

Значительно улучшит удобство использования интерфейса.

Хотя, может, оно уже есть? Стыковку можно включить путем сборки дополнительного пакета, но это не рекомендуется, так как еще остается ряд нерешенных проблем.

К версии 1.2 докация будет готова и скорее всего сразу встроена в среду.

Заявление : «Mac OS X: 10.4, только LCL 32-разрядная версия, без LCL может быть 64-разрядная версия».

Да, это впечатляет. Во-первых, это означает, что Lazarus собирает проекты для Mac OS X версии 10.4 или новее.

То есть поддерживаются 10.5 и 10.6 и 10.7 и 10.8 (на которых я сейчас запускаю Lazarus).

Проекты LCL могут быть только 32-битными.

Это связано с тем, что в Max OS X есть 2 основные системные библиотеки: Carbon и Coca-Cola. Carbon появился первым и представлял собой библиотеку функций.

Никаких проблем не возникло, чтобы начать строить на его основе LCL-бэкенд, что и было сделано.

После того, как Apple представила еще одну библиотеку, какао, которая вместо функций содержит классы Objective-C. Позже Apple заявила, что не будет делать библиотеку Carbon 64-битной, и вообще новые приложения должны разрабатываться только для какао.

Для взаимодействия с классами Objective-C в FPC был добавлен диалект, названный Цель-Паскаль .

В Lazarus также был добавлен бэкэнд для какао, но в настоящее время он находится на ранней стадии разработки.

Возможно (я приложу к этому усилия), к версии 1.2 это будет на уровне бэкенда для gtk2 и qt. Теги: #LAZARUS #freepascal #fpc #pascal #Разработка сайтов #delphi