Lazarus compilation options, where to change?

[TurboRascal]

I was wondering, where could I change the default compiler options for Lazarus, I see it's always compiled with -O1 and no smartlinking etc. I've seen those used both for IDE and LCL, and also as the default for IDE Packages.

I'd like to change those conservative settings with more optimized, so where can I do that? So far I've added the relevant switches to the "Configure Build Lazarus" dialog, but while smartlinking switches do work (not always, see below), I'm not sure what happens with the -O<num> switches, because then both my and the original -O<num> go to the compiler command line; it doesn't complain, but I'm not sure if it respects the first or the second optimization level switch... Also for some parts it complains that DWARF debug format conflicts with smartlinking and it switches to static linking. Is the DWARF debugging information necessary there? If not, I'd like to switch it off...

And another question by the way, as LCL is compiled without the "Smart Linkable" option, for me that means that no project could actually be compiled with smart linking; what gives?

[Martin_fr]

The IDE (and LCL), can be build via the tool menu or makefiles.

For the menu, you found the right place. For makefiles (not relevant, unless you open cmd.exe, and run make.exe) you give them to make.exe on command line.

However, the options you set in the menu. Most packages will respect them too. Some packages miss that setting. Each package has it's own "compiler option dialog" (reachable from the package mgr window).

Look under "Other", if "$(IDEBuildOptions)" (without quotes) is specified.

As for multiply -O1 -O2.
I think the last is respected. But it could also be the higher one.

In any case this will do O1
-O2 -O- -O1

-O- cancels out the previous

About dwarf, you have 3 choices:
1) Compile the LCL (and IDE) without any debug info -g-
- That is the least desirable. Even if you intend to never step into any LCL procedure while debugging.
- It will also loose the ability to inspect certain global variables in the LCL. e.g Application or other such globals
- If ever you run into trouble with the IDE, there will be no stacktraces => very hard to get help
2) use stabs -gs  (make sure it applies to all packages too, see above)
3) keep dwarf

At the moment dwarf has only a very few improvements over stabs (such as displaying selected properties (those that map to fields, instead of a getter), when inspecting objects)

But most future work, will go into dwarf.

oh, just to mention: stabs/dwarf are to ways of encoding debug info into the exe.

So, if you release your app, you will build with strip-symbols, and neither go into your app.

I haven't tested it, but your app should smart link, even if you did build packages with dwarf => just specify not to use it, when compiling and linking your app.

there are 2 switches.
- smart-linkable (prepare unit to be smart linked)
- smart link (actually do it)

Not sure, why smart-linkable is not set by default for the LCL (if that is the case, I never checked myself)

[TurboRascal]

Ok, so it seems default compilation options are in makefiles, since it is compiled with the same parameters either with make or from the menu. So I guess the makefiles should be edited? I wonder if there are also compiler options I can see (but not change) when I open LCL "package"...

About the menu compilation, if I understand correctly, later parameters override earlier, so since my additional switches are appended to the end, that should do the trick. What worried me more is how to handle the already set options like the DWARF debugging, but you reminded me that those can be removed by -g- switch (and -O- etc.), so that shouldn't pose a problem too...

[TurboRascal]

And another question concerning this, if LCL and other base libraries are compiled with low optimization and no smart linking, to me it would mean that those options are mainly useless to set in the project compiler options - the libraries will NOT get recompiled according to my settings, and since majority of the compiled code actually comes from them, the small percentage which is my code, which WILL be optimized and smartlinked, wouldn't really matter.

Did I get something wrong or this is a real problem?

[Leledumbo]

And another question concerning this, if LCL and other base libraries are compiled with low optimization and no smart linking, to me it would mean that those options are mainly useless to set in the project compiler options - the libraries will NOT get recompiled according to my settings

AFAIR, since LCL(Base) becomes a package, they will get recompiled as your project options (that may affect generated code) changes. I'm using trunk so I don't know whether it applies to stable release.

[TurboRascal]

AFAIR, since LCL(Base) becomes a package, they will get recompiled as your project options (that may affect generated code) changes. I'm using trunk so I don't know whether it applies to stable release.

Are you sure the packages get recompiled according to the project's compiler options? And even so, AFAIK LCL and FCL are "special" packages which don't get recompiled anyway... 

[Leledumbo]

Are you sure the packages get recompiled according to the project's compiler options? And even so, AFAIK LCL and FCL are "special" packages which don't get recompiled anyway... 

Yup, at least in my trunk installation

[Zoran]

And even so, AFAIK LCL and FCL are "special" packages which don't get recompiled anyway... 

In trunk version, LCL is no more "special".

[TurboRascal]

I find that very good news, unfortunately I use Release (or Fixes) versions for production use, so it will do me no good currently. I'm glad to hear that the next release (0.9.32?) will be like that, looking forward to that release.

So I guess that the code I produce now still has questionable state of optimizations and smartlinking?

[Leledumbo]

So I guess that the code I produce now still has questionable state of optimizations and smartlinking?

Perhaps. Just try recompiling ALL packages that you use with optimizations (with WPO if you really want the best result) and smartlinking enabled and see the differences yourself.

[TurboRascal]

Ok, I've already recompiled all individual packages as such and added relevant flags to "Build Lazarus", so I hope there would be some effect from that.

I must recheck now with those options, but before I've always noticed that enabling or disabling smartlinking in project compiler options gives me exactly zero size difference in (stripped) file size which made me come to the conclusion that smartlinking doesn't work at all.