[Lazarus] Applying optimization to the project units

[Mattias Gaertner]

On Thu, 25 Nov 2010 12:43:09 +0300
Max Vlasov <max.vlasov at gmail.com> wrote:

> On Thu, Nov 25, 2010 at 1:50 AM, Mattias Gaertner <nc-gaertnma at netcologne.de
> > wrote:
> 
> > On Thu, 25 Nov 2010 00:44:52 +0300
> > Max Vlasov <max.vlasov at gmail.com> wrote:
> >
> > > On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner <
> > > nc-gaertnma at netcologne.de> wrote:
> > >
> > > > On Thu, 25 Nov 2010 00:03:09 +0300
> > > > Max Vlasov <max.vlasov at gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > > sometimes it takes time for a Delphi developer to understand the
> > logic of
> > > > > fpc/lazarus packages and it's indeed content and full. Recently tried
> > to
> > > > > measure different performance related numbers for a project and
> > finally
> > > > got
> > > > > that I should change the level of optimization for packages, not for
> > the
> > > > > project if performance-related unit is in a package (CMIIW). But just
> > > > > wondering,.. these options actually consumes time so more often
> > > > developers
> > > > > leave optimization to fastest and when the time comes, rebuilds the
> > > > project
> > > > > with full optimization on. It looks like there's no single option
> > > > allowing
> > > > > do this for a given project in Lazarus, right? But even if there's an
> > > > option
> > > > > to rebuild all related packages, I still can't with one click change
> > this
> > > > > radiobox for every related package. Probably this won't be a problem
> > if I
> > > > > finally understand the logic and get used to it, just trying to find
> > > > whether
> > > > > I miss something
> > > >
> > > > You can add a macro (e.g. $(MyOptions) ) to the custom options of
> > > > a package and set the macro in the project build macros (e.g.
> > > > MyOptions=-O4). You need 0.9.29 for this.
> > > >
> > > >
> > > >
> > > >
> > > Mattias, it looks very promising, but will it affect the logic of "build
> > > all" command, currently from what I see from output it doesn't care about
> > > other packages units as long as their dates were not changed.
> >
> > If the build options changed the package is recompiled.
> >
> >
> > > In other
> > > words, what is the menu item I should use to "force" fpc compile not only
> > > units with changed dates, but all units from all packages using and with
> > my
> > > new  $(MyOptions)?
> >
> > No force needed.
> >
> >
> Mattias, there's still something missing in my understanding. I looked also
> at http://wiki.lazarus.freepascal.org/Macros_and_Conditionals and tried to
> do as suggested. My package now contains macro munilib_optimization with
> values 'General' and 'Full'
> 
> if munilib_optimization = 'General' then
>   CustomOptions:='-O1'
> else
>   CustomOptions:='-O3'
> 
> Then I try to change the value munilib_optimization in the main project
> Build modes (the project uses this package) . Ctrl-F9 -> Nothing changes
> (the corresponding .ppu and .o for the unit in question stays the same date
> regardless of my change), Build All -> Also nothing changes.

This should work.
Under what platform, fpc version?
Can you send me an example?

 
> The wiki also says that the scope of the changed value includes the package
> that introduced this option. Does it mean the the Compile button of this
> package is supposed to have the project compile context? So pressing Compile
> in the package window with different Macro values in the main project window
> should lead to different compile results?

Yes.


> If so, should the "Show options"
> button in the package Compile options show context-sensitive computed
> parameters (now it looks like the macro executed without taking the main
> project mode setting into consideration).

Strange.


> I'm asking because my observation
> about unexpected build results is based on non-direct symptoms, like
> different file dates and a sense that the optimization is in effect or not.
> It would be better to rely on more solid information.
> 
> btw, the package window sometimes freezes the IDE when I try to change
> something (It's when it constantly redraws trying to compile and resaves the
> corresponding lpk size making it either zero size or actual size. I reported
> a similar symptoms today about changing compiler message (fully
> reproducable), but when I experimented today with Build Modes/Macros,
> compiling the packages several times led to the same freezing behavior.

Please report this bug in the tracker.

Mattias