Lazarus as he is
Quite often, our reluctance 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 minds of others and form false negative ideas.
So in the comments on the recent topic “Lazarus 1.0 saw the light!” Some incorrect statements were made, as well as a number of unanswered questions. As a developer of Lazarus and FPC for quite some time, I can and want to answer most of the questions related to these products and dispel some incorrect assumptions.
Statement : The size of executable files is poor. The compiler, linker, etc. are to blame.
Some information on this topic can be obtained atwiki page .
So, the main component of the size of the executable file is debugging information. Debugging information is added by the FPC compiler when the "-g" switch is passed to it. FPC can generate 2 types of debugging information: obsolete stabs and modern dwarf (versions 2 or 3), which is also determined by the keys passed to the compiler. Both types of debugging information are understood by the gdb debugger. In Lazarus, you can enable / disable debugging information, and also determine 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 debugging symbol file. In this case, the debugging information will not be added to the executable file, and instead a link to the external debugging file will be placed.
The exception of debugging 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 RTTI swelling). It is not a matter of the compiler or the linker, which do their job correctly, but the whole point is in 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 the backends, no one really thought about the size of the executable files and wrote general methods in which he addressed all the frontend classes.
For example, the following code from the lcl \ interfaces \ win32 \ win32proc.pp module pulls the TCustomGroupBox, TCustomTabControl classes into the executable file even if you do not use them anywhere: Refactoring can solve this problem, but it requires considerable effort and time, which in conditions of shortage hands it might be better to spend on solving other problems. I must say that some efforts in this direction were made 2 or 3 years ago, which allowed to reduce the size of an empty project with a form by 300Kb. Statement : Lazarus once installed on Windows, and it was remembered that even the simplest program with a window and a button compiles sooo long.
The problem was when the 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 was not able to build under the 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 build speed (and as a result there is still no own linker for these platforms).
Now assembling and starting 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. Will greatly enhance 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 there are still a number of unresolved issues. By version 1.2, docking will be ready and most likely immediately built into the environment.
Statement : “Mac OS X: 10.4, LCL is only 32bit, non-LCL can be 64bit.” Yeah, impressive.
Firstly, it means that Lazarus collects projects for Mac OS X no lower than version 10.4. That is, 10.5 and 10.6 and 10.7 and 10.8 are supported (on which Lazarus is currently running on me). 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 was no problem starting to build an LCL backend based on it, which was done. After Apple introduced another cocoa library, which contains Objective-C classes instead of functions. Later, Apple announced that it would not make the carbon library 64 bit, and in general new applications should be developed only for cocoa.
To interact with Objective-C classes, a dialect called Objective-Pascal has been added to the FPC . A backend for cocoa has also been added to Lazarus, but it is currently under development. It is possible (I will make an effort to this), by version 1.2 it will be at the backend level under gtk2 and qt.
So in the comments on the recent topic “Lazarus 1.0 saw the light!” Some incorrect statements were made, as well as a number of unanswered questions. As a developer of Lazarus and FPC for quite some time, I can and want to answer most of the questions related to these products and dispel some incorrect assumptions.
Statement : The size of executable files is poor. The compiler, linker, etc. are to blame.
Some information on this topic can be obtained atwiki page .
So, the main component of the size of the executable file is debugging information. Debugging information is added by the FPC compiler when the "-g" switch is passed to it. FPC can generate 2 types of debugging information: obsolete stabs and modern dwarf (versions 2 or 3), which is also determined by the keys passed to the compiler. Both types of debugging information are understood by the gdb debugger. In Lazarus, you can enable / disable debugging information, and also determine 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 debugging symbol file. In this case, the debugging information will not be added to the executable file, and instead a link to the external debugging file will be placed.
The exception of debugging 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 RTTI swelling). It is not a matter of the compiler or the linker, which do their job correctly, but the whole point is in 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 the backends, no one really thought about the size of the executable files and wrote general methods in which he addressed all the frontend classes.
For example, the following code from the lcl \ interfaces \ win32 \ win32proc.pp module pulls the TCustomGroupBox, TCustomTabControl classes into the executable file even if you do not use them anywhere: Refactoring can solve this problem, but it requires considerable effort and time, which in conditions of shortage hands it might be better to spend on solving other problems. I must say that some efforts in this direction were made 2 or 3 years ago, which allowed to reduce the size of an empty project with a form by 300Kb. Statement : Lazarus once installed on Windows, and it was remembered that even the simplest program with a window and a button compiles sooo long.
if (TheWinControl is TCustomGroupBox) then
begin
...
end else
if TheWinControl is TCustomTabControl then
begin
...
end;
The problem was when the 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 was not able to build under the 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 build speed (and as a result there is still no own linker for these platforms).
Now assembling and starting 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. Will greatly enhance 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 there are still a number of unresolved issues. By version 1.2, docking will be ready and most likely immediately built into the environment.
Statement : “Mac OS X: 10.4, LCL is only 32bit, non-LCL can be 64bit.” Yeah, impressive.
Firstly, it means that Lazarus collects projects for Mac OS X no lower than version 10.4. That is, 10.5 and 10.6 and 10.7 and 10.8 are supported (on which Lazarus is currently running on me). 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 was no problem starting to build an LCL backend based on it, which was done. After Apple introduced another cocoa library, which contains Objective-C classes instead of functions. Later, Apple announced that it would not make the carbon library 64 bit, and in general new applications should be developed only for cocoa.
To interact with Objective-C classes, a dialect called Objective-Pascal has been added to the FPC . A backend for cocoa has also been added to Lazarus, but it is currently under development. It is possible (I will make an effort to this), by version 1.2 it will be at the backend level under gtk2 and qt.