Lazarus as it is

Quite often, our unwillingness to understand the issue and confidence in our own logic gives rise to incorrect assumptions. These assumptions, expressed as statements on a public platform, can firmly settle in the heads of others and form false negative ideas.

So in the comments to the recent topic “Lazarus 1.0 saw the light!” Some incorrect statements were made, and a number of unanswered questions were asked. Being a developer of Lazarus and FPC for quite a long time, I can and want to answer most of the issues related to these products and dispel some wrong assumptions.

Statement : The size of executable files leaves much to be desired. Blame the compiler, linker, etc.

Some information on this topic is available on the wiki page .
')
So, the main component of the size of the executable file is debug information. The FPC compiler adds debug information when the "-g" key is passed to it. FPC can generate 2 types of debug information: obsolete stabs and modern dwarf (version 2 or 3), which is also determined by the keys passed to the compiler. Both types of debug information are understood by the gdb debugger. In Lazarus, you can enable / disable debugging information, as well as define its appearance on the “Layout” tab in the project settings:

If you are building a project under Windows or Linux, you can create an external file of debugging symbols. In this case, the debugging information will not be added to the executable file, but instead a link to the external debugging file will be placed.

Excluding debug information reduces the size of an empty project with a form from 20MB to 1.6MB on Windows. But 1.6Mb is also more than 300Kb, which Delphi 7 gave out (Delphi XE, for example, already gives out much more due to the swelling of RTTI). The point here is not the compiler and not the linker, who do their work correctly, but the whole thing is in the LCL.

LCL - Lazarus Component Library architecturally consists of two parts: the front-end, a platform-independent class library for application developers (TForm, TButton, TLabel, ...) and the backend, the part responsible for implementing these components for a specific platform (win32, qt, gtk2,. ..). During the initial implementation of backends, no one particularly thought about the size of executable files and wrote general methods in which he applied to all classes of the front-end.

For example, the following code from the lcl \ interfaces \ win32 \ win32proc.pp module pulls into the executable file the TCustomGroupBox, TCustomTabControl classes, even if you never use them anywhere:
if (TheWinControl is TCustomGroupBox) then
begin
...
end else
if TheWinControl is TCustomTabControl then
begin
...
end;


Refactoring can solve this problem, but it requires considerable effort and time, which in conditions of lack of hands, it is possible to better spend on solving other problems. I must say that certain efforts in this direction were made 2 or 3 years ago, which made it possible to reduce the size of an empty project with a form of 300Kb.

Statement : Lazarus put once in Windows, and remember that even the simplest program with a window and a button is compiled sooo long.

The problem was when FPC used the GNU linker for Windows. But, in FPC 2.2 (and now Lazarus uses FPC 2.6), the problem was fixed by developing an integrated linker for Windows. In addition, at that time, the GNU linker did not know how to build a Win64 platform, which also prompted the development of its own built-in linker. It should be noted that under Linux and Darwin there were no such problems with the build speed (and as a result there is still no own linker for these platforms).

Now building and running an empty project with a form on my machine takes no more than 2 seconds.

Question : It's great if normal docking appears in Lazarus, as in Delphi 2006, for example. Greatly improve the convenience of the interface. Although, maybe he is already there?

Docking can be enabled by building an additional package, but this is not recommended, as long as there are a number of unsolved problems. For version 1.2, the docking will be ready and most likely immediately integrated into the environment.

The statement : "Mac OS X: 10.4, LCL is only 32bit, non-LCL can be 64bit." Yeah, impressive.

First, it means that Lazarus collects projects under Mac OS X no lower than version 10.4. That is, both 10.5 and 10.6 and 10.7 and 10.8 are supported (where I currently have Lazarus running). LCL projects can only be 32bit.

This is due to the fact that on Max OS X there are 2 main system libraries: carbon and cocoa. Carbon appeared first and was a library of functions. There were no problems starting to build an LCL backend on its basis, which was done. After Apple introduced another cocoa library, which instead of functions contains Objective-C classes. Later, Apple announced that it would not make the carbon 64 library a bit, and in general new applications should be developed only under cocoa.

To interact with Objective-C classes, a dialect has been added to FPC, called Objective-Pascal . A cocoa backend has also been added to Lazarus, but it is currently in early development. Perhaps (I will apply this effort), to version 1.2 it will be at the backend level under gtk2 and qt.