Довольно часто наше нежелание разбираться в вопросе и уверенность в собственной логике рождает неверные предположения. Эти предположения, высказанные как утверждения на публичной площадке, могут прочно осесть в чужих головах и сформировать ложные отрицательные представления.
Так в комментариях к недавней теме «Lazarus 1.0 увидел свет!» были высказаны некоторые неверные утверждения, а также задан ряд вопросов оставшихся без ответов. Являясь разработчиком Lazarus и FPC уже довольно продолжительное время, я могу и хочу дать ответ на большинство связанных с этими продуктами вопросов и развеять некоторые неверные предположения.
Утверждение: Размер исполняемых файлов оставляет желать лучшего. Виноват компилятор, компоновщик и др.
Некоторую информацию по данной теме можно получить на wiki-странице.
Итак, основная составляющая размера исполняемого файла — отладочная информация. Отладочную информацию добавляет компилятор FPC когда ему передан ключ "-g". FPC может генерировать 2 вида отладочной информации: устаревший stabs и современный dwarf (версии 2 или 3), что также определяется переданными компилятору ключами. Оба вида отладочной информации понимаются отладчиком gdb. В Lazarus включить/выключить отладочную информацию, а также определить ее вид можно на закладке «Компоновка» в параметрах проекта:
Если вы собираете проект под Windows или Linux, можно сформировать внешний файл отладочных символов. В этом случае в исполняемый файл отладочная информация добавляться не будет, а вместо нее будет помещена ссылка на внешний отладочный файл.
Исключение отладочной информации уменьшает размер пустого проекта с формой с 20Мб до 1,6Мб на Windows. Но, 1,6Мб тоже больше чем 300Кб, который выдавал Delphi 7 (Delphi XE, к примеру, уже выдает значительно больше из-за распухания RTTI). Дело тут не в компиляторе и не в компоновщике, которые делают свою работу верно, а все дело в LCL.
LCL — Lazarus Component Library архитектурно состоит их двух частей: фронтэнда — платформонезависимой библиотеки классов для разработчиков приложений (TForm, TButton, TLabel, ...) и бэкэнда — части отвечающей за реализацию этих компонент под конкретную платформу (win32, qt, gtk2, ...). При начальной реализации бэкэндов никто особо не задумывался о размере исполняемых файлов и писал общие методы, в которых обращался ко всем классам фронтэнда.
Например, следующий код из модуля lcl\interfaces\win32\win32proc.pp тянет в исполняемый файл классы TCustomGroupBox, TCustomTabControl, даже если вы их нигде не используете:
Решить эту проблему может рефакторинг, но он требует значительных усилий и времени, которые в условиях нехватки рук возможно лучше потратить на решение других проблем. Надо сказать, что определенные усилия в этом направлении были приложены 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 только 32bit, не-LCL могут быть 64bit». Да уж, впечатляет.
Во-первых, имеется в виду, что Lazarus собирает проекты под Mac OS X не ниже версии 10.4. То есть поддерживаются и 10.5 и 10.6 и 10.7 и 10.8 (на которой у меня сейчас запущен Lazarus). LCL проекты могут быть только 32бит.
Это связано с тем, что на Max OS X существуют 2 основные системные библиотеки: carbon и cocoa. Carbon появилась первой и представляла собой библиотеку функций. Не было никаких проблем начать строить на ее основе LCL бэкэнд, что и было сделано. После Apple представил еще одну библиотеку cocoa, которая вместо функций содержит классы Objective-C. Позже Apple объявил, что не будет делать библиотеку carbon 64 разрядной, и вообще новые приложения надо разрабатывать только под cocoa.
Для взаимодействия с Objective-C классами в FPC был добавлен диалект, получивший название Objective-Pascal. В Lazarus был также добавлен бэкэнд для cocoa, но он в настоящее время находится в стадии ранней разработки. Возможно (я приложу к этому усилия), к версии 1.2 он будет на уровне бэкэнда под gtk2 и qt.
Так в комментариях к недавней теме «Lazarus 1.0 увидел свет!» были высказаны некоторые неверные утверждения, а также задан ряд вопросов оставшихся без ответов. Являясь разработчиком Lazarus и FPC уже довольно продолжительное время, я могу и хочу дать ответ на большинство связанных с этими продуктами вопросов и развеять некоторые неверные предположения.
Утверждение: Размер исполняемых файлов оставляет желать лучшего. Виноват компилятор, компоновщик и др.
Некоторую информацию по данной теме можно получить на wiki-странице.
Итак, основная составляющая размера исполняемого файла — отладочная информация. Отладочную информацию добавляет компилятор FPC когда ему передан ключ "-g". FPC может генерировать 2 вида отладочной информации: устаревший stabs и современный dwarf (версии 2 или 3), что также определяется переданными компилятору ключами. Оба вида отладочной информации понимаются отладчиком gdb. В Lazarus включить/выключить отладочную информацию, а также определить ее вид можно на закладке «Компоновка» в параметрах проекта:
Если вы собираете проект под Windows или Linux, можно сформировать внешний файл отладочных символов. В этом случае в исполняемый файл отладочная информация добавляться не будет, а вместо нее будет помещена ссылка на внешний отладочный файл.
Исключение отладочной информации уменьшает размер пустого проекта с формой с 20Мб до 1,6Мб на Windows. Но, 1,6Мб тоже больше чем 300Кб, который выдавал Delphi 7 (Delphi XE, к примеру, уже выдает значительно больше из-за распухания RTTI). Дело тут не в компиляторе и не в компоновщике, которые делают свою работу верно, а все дело в LCL.
LCL — Lazarus Component Library архитектурно состоит их двух частей: фронтэнда — платформонезависимой библиотеки классов для разработчиков приложений (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 только 32bit, не-LCL могут быть 64bit». Да уж, впечатляет.
Во-первых, имеется в виду, что Lazarus собирает проекты под Mac OS X не ниже версии 10.4. То есть поддерживаются и 10.5 и 10.6 и 10.7 и 10.8 (на которой у меня сейчас запущен Lazarus). LCL проекты могут быть только 32бит.
Это связано с тем, что на Max OS X существуют 2 основные системные библиотеки: carbon и cocoa. Carbon появилась первой и представляла собой библиотеку функций. Не было никаких проблем начать строить на ее основе LCL бэкэнд, что и было сделано. После Apple представил еще одну библиотеку cocoa, которая вместо функций содержит классы Objective-C. Позже Apple объявил, что не будет делать библиотеку carbon 64 разрядной, и вообще новые приложения надо разрабатывать только под cocoa.
Для взаимодействия с Objective-C классами в FPC был добавлен диалект, получивший название Objective-Pascal. В Lazarus был также добавлен бэкэнд для cocoa, но он в настоящее время находится в стадии ранней разработки. Возможно (я приложу к этому усилия), к версии 1.2 он будет на уровне бэкэнда под gtk2 и qt.
