Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2010-11

Applying optimization to the project units

14 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Max Vlasov

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

Thanks in advance,

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101125/aedf2160/attachment.html>

Reply by email

Michael Van Canneyt
to Max Vlasov
Max Vlasov wrote 8 lines
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

Well, the same is true in Delphi, if you work with run-time packages. (not sure how it works when you don't use packages).

Michael.

Reply by email

Mattias Gaertner
to Max Vlasov: sometimes it takes time for a Delphi developer to understand the logic of fpc/lazarus…
Show quoted text 14 lines
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

Reply by email

Max Vlasov
to Mattias Gaertner

On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner <

Show quoted text 33 lines
wrote: On Thu, 25 Nov 2010 00:03:09 +0300 Max Vlasov 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. 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)?

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101125/a9ba767b/attachment.html>

Reply by email

Max Vlasov
to Michael Van Canneyt: Well, the same is true in Delphi, if you work with run-time packages. (not sure how it…

On Thu, Nov 25, 2010 at 12:26 AM, Michael Van Canneyt <

Show quoted text 29 lines
wrote: On Thu, 25 Nov 2010, Max Vlasov 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 > Well, the same is true in Delphi, if you work with run-time packages. (not sure how it works when you don't use packages).

Michael, as long as I remember and noticed, in Delphi without run-time packages if one uses "Build" every reachable pas source file is rebuilded in a brand-new dcu file (regardless of the dates and dcu internal info). As for optimization, I never even switched it off, but for conditional defines it was a safe way to ensure that all my 'penitum-only" ugly optimization windows won't show up in final project :) Hope I will finally find similar safe ways in Lazarus

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101125/8a3e9055/attachment.html>

Reply by email

Mattias Gaertner
to Max Vlasov: On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner < Mattias, it looks very promising,…
Show quoted text 37 lines
On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner < > wrote: > On Thu, 25 Nov 2010 00:03:09 +0300 > Max Vlasov 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

Reply by email

Unknown author
to Max Vlasov: On Thu, Nov 25, 2010 at 12:26 AM, Michael Van Canneyt < Michael, as long as I remember…
Max Vlasov wrote 34 lines
On Thu, Nov 25, 2010 at 12:26 AM, Michael Van Canneyt < > wrote: > > > On Thu, 25 Nov 2010, Max Vlasov 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 >> > > Well, the same is true in Delphi, if you work with run-time packages. > (not sure how it works when you don't use packages). > > Michael, as long as I remember and noticed, in Delphi without run-time packages if one uses "Build" every reachable pas source file is rebuilded in a brand-new dcu file (regardless of the dates and dcu internal info).

It can be.
I never ever put .pas files in the unit search path. It would take even Delphi lightyears to compile all :/

Michael.

Reply by email

Max Vlasov
to Mattias Gaertner: On Thu, 25 Nov 2010 00:44:52 +0300 If the build options changed the package is recompiled.

On Thu, Nov 25, 2010 at 1:50 AM, Mattias Gaertner <

Show quoted text 61 lines
wrote: On Thu, 25 Nov 2010 00:44:52 +0300 Max Vlasov wrote: > On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner < > > wrote: > > > On Thu, 25 Nov 2010 00:03:09 +0300 > > Max Vlasov 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.

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? 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). 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.

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101125/c0fa38ea/attachment-0001.html>

Reply by email

Mattias Gaertner
to Max Vlasov
Show quoted text 76 lines
On Thu, Nov 25, 2010 at 1:50 AM, Mattias Gaertner < > wrote: > On Thu, 25 Nov 2010 00:44:52 +0300 > Max Vlasov wrote: > > > On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner < > > > wrote: > > > > > On Thu, 25 Nov 2010 00:03:09 +0300 > > > Max Vlasov 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?

Show quoted text 5 lines
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.

Show quoted text 11 lines
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

Reply by email

Max Vlasov
to Mattias Gaertner

On Thu, Nov 25, 2010 at 3:47 PM, Mattias Gaertner <

Show quoted text 104 lines
wrote: On Thu, 25 Nov 2010 12:43:09 +0300 Max Vlasov wrote: > On Thu, Nov 25, 2010 at 1:50 AM, Mattias Gaertner < > > wrote: > > > On Thu, 25 Nov 2010 00:44:52 +0300 > > Max Vlasov wrote: > > > > > On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner < > > > > wrote: > > > > > > > On Thu, 25 Nov 2010 00:03:09 +0300 > > > > Max Vlasov 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?

Mattias, it's great that it should work as I expected, let's see what I did wrong :)

Lazarus 0.9.29 r28448 FPC 2.4.2 i386-win32-win32/win64

The following actions to reproduce:

------------------------------------------ Create package conditionalpackage.lpk,

------------------------------------------- add this unit to the package

unit conditionalunit;
{$mode objfpc}{$H+}
interface uses Classes, SysUtils, Dialogs, MsgUnit;
procedure ShowProjDependentMessage;
implementation
procedure ShowProjDependentMessage;
begin
  MessageDlg(UnitMessage, mtInformation, [mbOk], 0);
end;
end.

------------ Place file MsgUnit in subfolder Ver1

unit MsgUnit;
interface
const
  UnitMessage = 'This is first version';
implementation
end.

------------ And this one in the subfolder Ver2

unit MsgUnit;
interface
const
  UnitMessage = 'This is second version';
implementation
end.

----------------------------------------

Builds macro
ConditionalPackage_Version
with subvalues 1 and 2

Conditional text

if ConditionalPackage_Version = '1' then
  UnitPath := 'Ver1\'
else
  UnitPath := 'Ver2\'

--------------------

Create a project that uses this package and conditionalunit, place a button, call ShowProjDependentMessage.

If we did nothing, the message will be This is second version'. If I go the the project Build macro and chose version 1 then ..
- Ctrl-F9 the message is still the same (second version),
- Build all -> still the same,
- Compile in the package window, compile project - still the same.

Max Vlasov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101125/45da31b2/attachment.html>

Reply by email

Mattias Gaertner
to Max Vlasov
Show quoted text 187 lines
On Thu, Nov 25, 2010 at 3:47 PM, Mattias Gaertner < > wrote: > On Thu, 25 Nov 2010 12:43:09 +0300 > Max Vlasov wrote: > > > On Thu, Nov 25, 2010 at 1:50 AM, Mattias Gaertner < > > > > wrote: > > > > > On Thu, 25 Nov 2010 00:44:52 +0300 > > > Max Vlasov wrote: > > > > > > > On Thu, Nov 25, 2010 at 12:36 AM, Mattias Gaertner < > > > > > wrote: > > > > > > > > > On Thu, 25 Nov 2010 00:03:09 +0300 > > > > > Max Vlasov 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? > > > Mattias, it's great that it should work as I expected, let's see what I did wrong :) Lazarus 0.9.29 r28448 FPC 2.4.2 i386-win32-win32/win64 The following actions to reproduce: ------------------------------------------ Create package conditionalpackage.lpk, ------------------------------------------- add this unit to the package unit conditionalunit; {$mode objfpc}{$H+} interface uses Classes, SysUtils, Dialogs, MsgUnit; procedure ShowProjDependentMessage; implementation procedure ShowProjDependentMessage; begin MessageDlg(UnitMessage, mtInformation, [mbOk], 0); end; end. ------------ Place file MsgUnit in subfolder Ver1 unit MsgUnit; interface const UnitMessage = 'This is first version'; implementation end. ------------ And this one in the subfolder Ver2 unit MsgUnit; interface const UnitMessage = 'This is second version'; implementation end. ---------------------------------------- Builds macro ConditionalPackage_Version with subvalues 1 and 2 Conditional text if ConditionalPackage_Version = '1' then UnitPath := 'Ver1\' else UnitPath := 'Ver2\' -------------------- Create a project that uses this package and conditionalunit, place a button, call ShowProjDependentMessage. If we did nothing, the message will be This is second version'. If I go the the project Build macro and chose version 1 then .. - Ctrl-F9 the message is still the same (second version), - Build all -> still the same, - Compile in the package window, compile project - still the same.

Fixed. Please test.

Mattias

Reply by email

Max Vlasov
to Mattias Gaertner

On Thu, Nov 25, 2010 at 5:10 PM, Mattias Gaertner <

Show quoted text 19 lines
wrote: > Create a project that uses this package and conditionalunit, place a button, > call ShowProjDependentMessage. > > If we did nothing, the message will be This is second version'. If I go the > the project Build macro and chose version 1 then .. > - Ctrl-F9 the message is still the same (second version), > - Build all -> still the same, > - Compile in the package window, compile project - still the same. > Fixed. Please test. Mattias

Mattias, it seems still something doesn't work, I tried with simple make, then make clean all, the same result

version Lazarus 0.9.29 r28480 FPC 2.4.2 i386-win32-win32/win64

- The route only works if I change the property, go to package, press compile, return to project, compile the project, the phrases change in this case in the program I run

- An observation making comparison with previous version difficult: the macro block started to work only when I changed '1' to 1 in the expression (removed quotes). The screenshot at wiki shows True in quotes ('True'), but in my case only removing make it work at least the way I described in the first observation.

- The package now correctly shows the right computed compiler options if I change the macro value in the project options (changed -FuVer2 and -FuVer1 accordingly).

- Still neither Build nor Build All of the project affects the result of compilation. So I have a feeling that the logic behind "Rebuild the package as needed" doesn't take new macro option into account. "Build all" shows some information about compiling the package (condpkg.pas(10,18) Hint: Unit "conditionalunit" not used in CondPkg), but the result of the project compilation different to what it does when I explicitly press Compile in the package window.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101125/33138d25/attachment.html>

Reply by email

Mattias Gaertner
to Max Vlasov
Show quoted text 28 lines
On Thu, Nov 25, 2010 at 5:10 PM, Mattias Gaertner < > wrote: > > Create a project that uses this package and conditionalunit, place a > button, > > call ShowProjDependentMessage. > > > > If we did nothing, the message will be This is second version'. If I go > the > > the project Build macro and chose version 1 then .. > > - Ctrl-F9 the message is still the same (second version), > > - Build all -> still the same, > > - Compile in the package window, compile project - still the same. > > > > Fixed. Please test. > > Mattias > > Mattias, it seems still something doesn't work, I tried with simple make, then make clean all, the same result version Lazarus 0.9.29 r28480 FPC 2.4.2 i386-win32-win32/win64 - The route only works if I change the property, go to package, press compile, return to project, compile the project, the phrases change in this case in the program I run

Fixed.

Show quoted text 5 lines
- An observation making comparison with previous version difficult: the macro block started to work only when I changed '1' to 1 in the expression (removed quotes). The screenshot at wiki shows True in quotes ('True'), but in my case only removing make it work at least the way I described in the first observation.

Fixed.

- The package now correctly shows the right computed compiler options if I change the macro value in the project options (changed -FuVer2 and -FuVer1 accordingly).

:)

- Still neither Build nor Build All of the project affects the result of compilation.

It should now.

Show quoted text 6 lines
So I have a feeling that the logic behind "Rebuild the package as needed" doesn't take new macro option into account. "Build all" shows some information about compiling the package (condpkg.pas(10,18) Hint: Unit "conditionalunit" not used in CondPkg), but the result of the project compilation different to what it does when I explicitly press Compile in the package window.

Mattias

Reply by email

Max Vlasov
to Mattias Gaertner

On Thu, Nov 25, 2010 at 7:21 PM, Mattias Gaertner <

Show quoted text 35 lines
wrote: > compile, return to project, compile the project, the phrases change in this > case in the program I run > - The route only works if I change the property, go to package, press Fixed. > - An observation making comparison with previous version difficult: the > macro block started to work only when I changed '1' to 1 in the expression > (removed quotes). The screenshot at wiki shows True in quotes ('True'), but > in my case only removing make it work at least the way I described in the > first observation. Fixed. > - The package now correctly shows the right computed compiler options if I > change the macro value in the project options (changed -FuVer2 and -FuVer1 > accordingly). :) > - Still neither Build nor Build All of the project affects the result of > compilation. It should now.

Mattias, great job, and, what impressed me, very fast :) I did a quick test, confirmed, everything works fine including the quotes. If I find something new, I will let you know, maybe this time in the bug tracker. You know, the feature is so new and as many in Lazarus have no analogy in Delphi, so not always one can be sure something is really wrong :)

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101126/e95b916d/attachment.html>

Reply by email