My test program contains a simple form with a few buttons and comboboxes and a memo. Additionally I have a unit defining a communications class, which uses SdpoSerial.

I had not looked at the size before but now I see that the test executable is now 13 Mbytes! Is this normal? I would not have expected this size considering that the program contains so little yet...

I use FPC 2.4.2 and Lazarus fixes_0_9_30 and SdpoSerial 0.1.4 on Windows XP.

Bo Berglund

Bo Berglund wrote

I had not looked at the size before but now I see that the test executable is now 13 Mbytes! Is this normal? I would not have expected this size considering that the program contains so little yet...

http://wiki.lazarus.freepascal.org/Size_Matters

Trying to digest but very hard...
Isn't there a simpler setting in Lazarus that can switch on/off optimization or debug data generation?
I guess that the exe is big because it contains debug stuff, but that a single form created as a default project and where I added 10 buttons, 3 spinedits, 1 combobox and 5 shapes as signal "lamps" plus a couple of units with pretty straightforward object definitions and the SdpoSerial component could turn out as a 13 Mb exe file is beyond my grasp.
THe link above brings me to a page where big seems to start at 6 Mb....

You might want to look at the lazarus faq:
http://wiki.lazarus.freepascal.org/Lazarus_Faq

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110217/1062f1e6/attachment.html>

'strip --strip-all programname.exe' when you are ready to deliver.

There are other optimizations that can be used in the code generation itself

Op 2011-02-17 23:43, Bo Berglund het geskryf:

> > http://wiki.lazarus.freepascal.org/Size_Matters Trying to digest but very hard...

Yes, size is dependent on debug information and smartlinking. To make your executables smaller you have a few options:

1) Strip debug information and enable smart linking. Project Options -> Code generation
project Options -> Linking.

The FPC parameters are:
-CX -XX -Xs

2) Use a "lighter" GUI toolkit. fpGUI produces much smaller executables than LCL (handy for embedded work). MSEgui is somewhere in the middle.

I must add in LCL's defence... A simple application might end up having a 10MB executable, but then it grows very slowly from there. If you have to plot the executable size dependant on the size of the application, the growth is NOT linear.

Regards,
- Graeme -

Yes I know about this non-linear behaviour from Delphi. But it started at a much lower fixed size. BTW we always compiled only for a single exe in Delphi, so the concept of runtime libraries are not confusing this comparison.

Couldn't Lazarus be "smart" about the code generation as follows:
1) When one clicks the run button (green arrow) lazarus creates the exe file with embedded debug information such that breakpoints etc work for debugging.

2) When one uses the build function Lazarus does NOT use the compile option to enter debug data into the exe, thus creating the slimmer file.

With this one would get the best of both worlds, right?

Op 2011-02-18 12:43, Bo Berglund het geskryf:

With this one would get the best of both worlds, right?

I'm pretty sure with Lazarus' new "build modes" this is probably possible already. I haven't played with that feature yet, so I can't give a definitive answer.

Alternatively, you can also tell Lazarus/FPC to generate an external file (not part of the executable) for the debug information. Thus you have a small executable, and a separate file that contains the debugging info. GDB will then look at both for debugging support. Again, not something I tried myself yet, but have heard of others that use it like this.

Regards,
- Graeme -

?

Bo Berglund hat am 18. Februar 2011 um 11:43
geschrieben:

No, that would be a bug. "Compile" let the compiler compile all new, "Build" recompiles all units of the project.
?
You can define a second build mode "release" and enable whatever optimization you think is appropriate for your customers.?
?

Mattias?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110218/68873f5a/attachment.html>

The "Use external gdb debug symbol file (-Xg)" linking option works well for me. It creates a 30MB .dbg file and a 5.4MB executable for my current project.

With this set, the "strip symbols from executable (-Xs)" option has no impact and unchecking the -gl option only shaves of 6KB!

No, that would be a bug. "Compile" let the compiler compile all new, "Build" recompiles all units of the project.

When I click Run, a lot of untouched units are recompiled every time... What exactly is the difference between "Run", "Build", "Build all" and "Quick compile"?

When I do a "build all", it takes 10 seconds for my project. Then I touch an insignificant unit and most, but not all, units are recompiled. 6 seconds. "Quick compile" and "Build" seem to be doing the same as "Run" (without running of course).

Regards,

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110218/3193429c/attachment.html>

That is probably what I will try tonight then. Seems reasonable to me.

Yes, sorry for the fuzz.
Run checks if something changed and invokes a "Build". Then start program or debugger.
Build calls compiler.
Build all calls compiler with -B.
Quick compile calls compiler with options to omit assembling and linking.

When I do a "build all", it takes 10 seconds for my project. Then I touch an insignificant unit and most, but not all, units are recompiled. 6 seconds.

Maybe linking your program takes a few seconds.

:)

Mattias

With this one would get the best of both worlds, right?

Nope, some people does debugging externally from command line sometimes because the need of specific gdb command. Doing so would disallow this "feature".

i recently ran into this in plain FPC when i switched from DEBUG to RELEASE mode and had to re-enter the unit and include directories the project i'm working on needed... it was a bit of a shock to have them "lost" when switching modes but a quick look in the fpc.cfg showed me the problem :) no clue if this also applies to lazarus, though... i've not even attempted to use laz's graphical environment for this particular console only tool build...

With this option on the exe file reduced from 13 Mb to 1.6 Mb! :-) Thanks!

When you create a new build mode in Lazarus the current one is copied.

When you add unit paths, they are not automatically copied to the other build modes. There is a dialog showing the differences between the build modes.

Mattias

I have found the cause! Some months ago I started outputting the .o and .ppu files into a subdirectory. Ever since, for each unit that had an old .o and .ppu in the main directory, Build would recompile it. This caused a recompile of more than half of all my code every time I ran the project (if there had been a change).

Now everything makes a lot more sense.

* Run will invoke Build if a change has been detected to the source. (Some source file with a later date than ProjectName.compiled or ProjectName.exe?)
* Build recompiles all units with source files that are newer than their object files (but looks in the main directory first for the object files) and of course any other dependent units if needed. (When any compiler switches were changed, Build All is invoked instead?).
* Build All recompiles all used units regardless.
* Quick compile does a Build without linking.

I'm sure the above summary could be improved upon.

Regards,

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110219/54488e8e/attachment.html>

When you create a new build mode in Lazarus the current one is copied.

Why that?

When I want to maintain different branches of a project, I can already save the project under a new name. But IMO Release and Debug versions only should change compiler options, not the units.

DoDi

Because normally you want to change only a few things like optimization flags and keep the rest (e.g. search paths, target file name, verbosity, ...).

When I want to maintain different branches of a project, I can already save the project under a new name. But IMO Release and Debug versions only should change compiler options, not the units.

I can't follow you here. Why should build modes change units?

Mattias

i kinda wondered the same thing... but then i thought about it a little more and realized that one could have "debug" units and include files that are the same as the release ones but without the debug stuff included...

another thing is do you really want to rebuild everything in your project when switching modes and including (or not) all the additional debug info?

yes, i know the above could easily be handled with a define but not everyone thinks or operates the same way ;)

The *rest* is of my concern. It should not be copied, instead be used as is, in every mode.

What fun when you debug a new version, and then ship the old one, built from the old release build mode :-(

DoDi

Ehm, maybe you misunderstood the term "build mode" in Lazarus?

http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Build_modes

Mattias