Lazarus

Announcements => Lazarus => Topic started by: Martin_fr on April 03, 2019, 06:35:39 pm

Title: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 03, 2019, 06:35:39 pm
The Lazarus team is glad to announce that:

      The release of Lazarus 2.0.2

has been scheduled for around

      16th to 18th April 2019

This release will be built with FPC 3.0.4.
The previous release Lazarus 2.0.0 was built with FPC 3.0.4 as well.

Here is the list of fixes for Lazarus 2.0.2 (since 2.0.0):
http://wiki.freepascal.org/Lazarus_2.0_fixes_branch

We would invite everyone to provide their feedback to help us improve this upcoming release. Please let as know in particular:
- Any fixes made to trunk, that you believe should still be merged to
  the fixes branch (fixes that are not listed on the above wiki page)
- Any regressions that happened in fixes branch since the last release
- Other urgent matters, you believe we should know before the release.

Please attempt to provide your feedback by: 10th April 2019

More info on our release process can be found at (work in progress):
http://wiki.lazarus.freepascal.org/Lazarus_release_engineering

Information about the previous release:
http://wiki.lazarus.freepascal.org/Lazarus_2.0.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.0.4

The intended minimum requirements for the release will be:

Windows:
   2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.

FreeBSD/Linux:
   gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.

Mac OS X:
   10.5 to 10.12; Carbon (32bit), Cocoa (64bit, beta), qt and qt5 (32 or 64bit).
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: lucamar on April 03, 2019, 07:06:33 pm
Any reason for a new release so soon after the previous? I mean, it has been less than two months since versoin 2.0.0

Not that I'm complaining, mind you; I'm just curious.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 03, 2019, 08:54:30 pm
No particular reason.

Those are the dates tagged in mantis (they may not be exact to the day, and not sure if older ones are correct)
Code: [Select]
2.0    2019-02-05
1.8.6  2018-08-01
1.8.4  2018-05-21
1.8.2  2018-03-01
1.8    2017-12-05
1.6.4  2017-03-01
1.6.2  2016-11-15
1.6    2016-02-18
1.4.4  2015-10-05
1.4.2  2015-07-14
1.4    2015-04-20
1.2.6  2014-10-12
1.2.4  2014-06-15
1.2.2  2014-04-21
1.2.0  2014-03-01
1.0.14 2013-11-15
1.0.12 2013-08-24
1.0.10 2013-03-26
1.0.8  2013-03-01
1.0.6  2013-02-01
1.0.4  2012-10-05
1.0.2  2012-09-29
1.0.0  2012-08-28

So we used to have a 2 to 3 month cycle before. Though the cycle will vary depending on how we have time. (There should have been a 1.8.8, but we were busy preparing 2.0)

Last release was early Feb, so it will be 2.5 month. And we do have a nice amount of fixes, so it would be good to make them available.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: lucamar on April 03, 2019, 09:59:28 pm
So we used to have a 2 to 3 month cycle before.

Oh, I guess I've been mislead by my own update cycle, which used to be between 6 months to one year. No wonder I always missed the X.Y.0 releases :D
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: fcu on April 03, 2019, 10:48:45 pm
i hope you remove the flickering caused by the splitter component
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Oscar Vazquez on April 03, 2019, 11:59:47 pm
Excellent, when they enabled the Contrains to use them at the Tfield level in the data module.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: BeniBela on April 04, 2019, 12:40:47 am
Perhaps someone can find a fix for https://bugs.freepascal.org/view.php?id=27401 ?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: ASBzone on April 04, 2019, 01:00:18 am
1.8.6  2018-08-01

Was there actually a 1.8.6 release?  I thought we only got up to 1.8.4 before 2.0?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 04, 2019, 04:36:47 am
1.8.6  2018-08-01

Was there actually a 1.8.6 release?  I thought we only got up to 1.8.4 before 2.0?
The tags in mantis are created in advance. They always go one step further. This is so bug-targets can be set for future releases.

When a future minor release is replaced by a new major released, the correct thing would be to move any issue from that tag, to the new major tag. And then remove the no longer needed tag.
But no one has yet bothered to go through that work...



About individual issues mentioned in other posts above:
Please find the relevant issue report on Mantis https://bugs.freepascal.org/ and check if they are resolved. Mantis should tell you the revision, and that allows you to check http://wiki.freepascal.org/Lazarus_2.0_fixes_branch if the fix will be in 2.0.2

If an issue is not reported on Mantis, then please add it there.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 04, 2019, 11:08:55 am
Any chance we'll see updated Help builds for the release?

LCL and LazUtils online (SourceForge) are at version 0.9.3.
LCL and LazUtils CHMs are at version 1.2.4.6. (Windows Installer for Lazarus 2.0.0).

Sure would be nice to get something more recent.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 04, 2019, 01:54:37 pm
I am aware that the ones at sourceforge are outdated.

I am trying to find out how my chm viewer can be made to show the version (I seem to only have the file date)

lcl and lazutils were rebuild before the release was made https://svn.freepascal.org/svn/lazarus/binaries
And the installer seems to have the same version of files.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 04, 2019, 11:41:24 pm
I am aware that the ones at sourceforge are outdated.

I am trying to find out how my chm viewer can be made to show the version (I seem to only have the file date)

lcl and lazutils were rebuild before the release was made https://svn.freepascal.org/svn/lazarus/binaries
And the installer seems to have the same version of files.

The only mechanism I can find is to look at the generated documentation for the lcl_version and laz_version topics. In the chms, lcl_Version contains '1.2.4.6'. And those were installed, as I mentioned, with the Windows installler for Lazarus 2.0.0.

I vote for putting the version info in the page footer for generated pages.

EDIT:

I just looked again. I was wrong, lcl_version is actually 1.0.12.

EDIT:

I downloaded the separate zip file with Doc. It is in fact at version '1.8.5.0'. So that's good. But not having them in the installer isn't.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 05, 2019, 12:54:08 am
The version example in the help text is not automatically updated.

From the file docs/xml/lcl/lclversion.xml (that is one of the source file from which the help is build)
Code: [Select]
<p>For example, if the LCL version is 1.2.4.6, lcl_fullversion will be 1020406</p>
That is the text that goes into the help. Even for trunk. It is still correct. It is an example, so it does not have to be the current version.

The 1.0.12 is in the same file, as is 0.9.25

Quote
I downloaded the separate zip file with Doc. It is in fact at version '1.8.5.0'. So that's good. But not having them in the installer isn't.
And that number appears at text, in the same location as the 1.2.4.6?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 05, 2019, 01:19:56 am
The version example in the help text is not automatically updated.

From the file docs/xml/lcl/lclversion.xml (that is one of the source file from which the help is build)
Code: [Select]
<p>For example, if the LCL version is 1.2.4.6, lcl_fullversion will be 1020406</p>
That is the text that goes into the help. Even for trunk. It is still correct. It is an example, so it does not have to be the current version.

The 1.0.12 is in the same file, as is 0.9.25

Quote
I downloaded the separate zip file with Doc. It is in fact at version '1.8.5.0'. So that's good. But not having them in the installer isn't.
And that number appears at text, in the same location as the 1.2.4.6?

The file at https://svn.freepascal.org/svn/lazarus/binaries/docs/chm/ has the following:

Code: [Select]
lcl_version
LCL version string

Declaration
Source position: lclversion.pas line 46

const lcl_version = laz_version;

Description
Contains the LCL version string, e.g. 1.0.12.

I am assuming this is is the same file used in the installer build.

The zip file at SourceForge contains:

Code: [Select]
lcl_version
LCL version string

Declaration
Source position: lclversion.pas line 40

const lcl_version = '1.8.5.0';

Description
Contains the LCL version string, e.g. 1.0.12.

Which has a real value for the constant.

The installed version being older (or even different) than the zip file on SourceForge is an issue. Most folks are using what gets installed.
 
The online help is a different matter altogether.

Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 05, 2019, 02:31:04 am
In that case th zip is outdated.

Revision: 57504
Date: 14 March 2018 09:21:54
LazUtils: Add unit LazVersion. Use it also for LCLVersion. Issue #33418,

Back then (that was Lazarus 1.9 svn) the unit was changed. The actual number is now stored in laz_version, and lcl_version became a forwarder.

So the doc for lcl_version should show
Code: Pascal  [Select]
  1. const lcl_version = laz_version;
as the correct declaration.

---

The reason this is a bit tricky to discuss is: I do build the win installer, but not the docs. However the person who does build the docs had notified me before the 2.0.0 release that they were updated in svn. And the win installer contains the files from svn.

So the only knowledge I had on the docs was his word. I trust that, but it does not mean an error could not have happened along the way.
I did enquire with him, but had not yet gotten a response.

It now seems the doc zip needs updating.
I don't know if a footer with the version could be added to the docs. So I can't currently comment on how to make it easier to check their version...
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: bylaardt on April 05, 2019, 05:01:40 am
it is very common for me to generate .ps files with TPostScriptCanvas greater than 2gB (accounting reports), but TStringList does not save files of this size, see:

From rtl/objclass/classes/stringl.inc[/color]:
Code: Pascal  [Select]
  1. Function TStrings.GetTextStr: string;
  2.  
  3. Var P : Pchar;
  4.     I,L,,NLS: Longint;
  5.     S,NL : String;
  6.  
  7. begin
  8.   CheckSpecialChars;
  9.   // Determine needed place
  10.   if FLineBreak<>sLineBreak then
  11.     NL:=FLineBreak
  12.   else
  13.     Case FLBS of
  14.       tlbsLF   : NL:=#10;
  15.       tlbsCRLF : NL:=#13#10;
  16.       tlbsCR   : NL:=#13;
  17.     end;
  18.   L:=0;
  19.   NLS:=Length(NL);
  20.   For I:=0 to count-1 do
  21.     L:=L+Length(Strings[I])+NLS;
  22.   if SkipLastLineBreak then
  23.     Dec(L,NLS);
  24.   Setlength(Result,L);
  25.   P:=Pointer(Result);
  26.   For i:=0 To count-1 do
  27.     begin
  28.     S:=Strings[I];
  29.     L:=Length(S);
  30.     if L<>0 then
  31.       System.Move(Pointer(S)^,P^,L);
  32.     P:=P+L;
  33.     if (I<Count-1) or Not SkipLastLineBreak then
  34.       For L:=1 to NLS do
  35.         begin
  36.         P^:=NL[L];
  37.         inc(P);
  38.         end;
  39.     end;
  40. end;
  41.  

L is delimited by 2gb because it is longint.

My workarround in ever release is change the from lazarus/lcl/postscriptcanvas.pas: to:
Code: Pascal  [Select]
  1. procedure TPostScriptPrinterCanvas.SaveToFile(aFileName : string);
  2. Var
  3.   f:TextFile;
  4.   i:LongInt;
  5. begin
  6.   assignfile(f,ExpandFileNameUTF8(aFileName));
  7.   rewrite(f);
  8.   for i:= 0 to fHeader.count-1 do
  9.     writeln(f,fHeader[i]);
  10.   for i:= 0 to fDocument.count-1 do
  11.     writeln(f,fDocument[i]);
  12.   closefile(f);
  13. end;    

@martin_fr: Is this a rtl/FPC or a lcl/Lazarus issue to fix?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Cyrax on April 05, 2019, 05:49:41 am
TPostScriptCanvas should change type of property PostScript to TMemoryStream or other TStream subclass. String type have memory limitation (its internal length variable is 4 bytes wide)  even on 64-bit systems.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: engkin on April 05, 2019, 06:34:37 am
String type have memory limitation (its internal length variable is 4 bytes wide)  even on 64-bit systems.
Code: Pascal  [Select]
  1.   TAnsiRec = Record
  2.     CodePage    : TSystemCodePage;
  3.     ElementSize : Word;
  4. {$ifdef CPU64} 
  5.     { align fields  }
  6.         Dummy       : DWord;
  7. {$endif CPU64}
  8.     Ref         : SizeInt;
  9.     Len         : SizeInt;
  10.   end;
  11.  

Code: Pascal  [Select]
  1. {$ifdef CPU64}
  2.   SizeInt = Int64;
  3. ...
  4. {$ifdef CPU32}
  5.   SizeInt = Longint;
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: PeterX on April 05, 2019, 09:40:06 am
I would like to see this HighDPI scaling bug of the Lazarus IDE fixed ..

0035231: High DPI - value "DesignTimePPI" is different between *.lfm file and Object Inspector
related with
0034841: AnchorDocking: Loading layouts does not consider HighDPI scaling

For my current project I found out that it's enough
to just move the MainForm to update the PPI in my project
after I opened my project on a PC with different Windows Scaling Settings.

But also the MainForm looses it's position when moving the project beween
Windows PCs with different PPI settings. So also the project's MainForm's
TOP and RIGHT position are not HighDPI scaled .. sucks ..
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: JuhaManninen on April 05, 2019, 11:18:55 am
I would like to see this HighDPI scaling bug of the Lazarus IDE fixed ..

0035231: High DPI - value "DesignTimePPI" is different between *.lfm file and Object Inspector
related with
0034841: AnchorDocking: Loading layouts does not consider HighDPI scaling
This is not related to Lazarus 2.0.2 release but I answer here anyway ...
Did you test the patch uploaded by Ondrej? Does it help? If it does, can you improve it so a project would not get saved always?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: VTwin on April 05, 2019, 03:37:40 pm
Great news! I'm glad there is such active progress.

I made 7 bug reports regarding the Cocoa IDE in December. Some were major usability issues, like contextual menus not working, the inability to delete a control once placed on a form, etc. Six are still listed as "new". I'm hoping these can be addressed before the release.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Cyrax on April 05, 2019, 03:57:51 pm
String type have memory limitation (its internal length variable is 4 bytes wide)  even on 64-bit systems.
Code: Pascal  [Select]
  1.   TAnsiRec = Record
  2.     CodePage    : TSystemCodePage;
  3.     ElementSize : Word;
  4. {$ifdef CPU64} 
  5.     { align fields  }
  6.         Dummy       : DWord;
  7. {$endif CPU64}
  8.     Ref         : SizeInt;
  9.     Len         : SizeInt;
  10.   end;
  11.  

Code: Pascal  [Select]
  1. {$ifdef CPU64}
  2.   SizeInt = Int64;
  3. ...
  4. {$ifdef CPU32}
  5.   SizeInt = Longint;

Oh, I see.  :-[
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: PeterX on April 05, 2019, 04:23:39 pm
This is not related to Lazarus 2.0.2 release but I answer here anyway ...
Did you test the patch uploaded by Ondrej? Does it help? If it does, can you improve it so a project would not get saved always?
I will test this tonight. And then report.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: JuhaManninen on April 05, 2019, 05:26:28 pm
I made 7 bug reports regarding the Cocoa IDE in December. Some were major usability issues, like contextual menus not working, the inability to delete a control once placed on a form, etc. Six are still listed as "new". I'm hoping these can be addressed before the release.
If you provide patches now, it may be possible to merge them.
But hurry up, changes should also be tested before they go into a release.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: VTwin on April 05, 2019, 05:47:28 pm
If you provide patches now, it may be possible to merge them.
But hurry up, changes should also be tested before they go into a release.

Thanks. I'd need to dive into the Cocoa widgets and IDE internals, before I could hope to provide a patch. Not something I could do fast. I provided test applications to illustrate the bugs, if anyone else has the skills.

https://bugs.freepascal.org/view.php?id=34663
https://bugs.freepascal.org/view.php?id=34717
https://bugs.freepascal.org/view.php?id=34716
https://bugs.freepascal.org/view.php?id=34718
https://bugs.freepascal.org/view.php?id=34630
https://bugs.freepascal.org/view.php?id=34629


Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 05, 2019, 05:57:36 pm
Quick reminder:

1) If you have an issue at any time (independent of this announcement, or when the next release may be), you should make sure it is in the bug-tracker.

2) If you believe a bug report in the tracker may have been overlooked, you can always mention this. The best place for that is on the mail list. Issues of this kind on the forum may not get the full attention, as some team members are only/mainly on the mail list.

However this does not mean that everyone should constantly push there issues. The way a bug report and fix works is:
- report is made
- a team member (who maintains the related code or is familiar with it) will volunteer to take the issue (assign it to him).
- that team member then decides where the issue ends up in his personal priority (compared to other issues).
 And when that team member has spare free time (between his job and personal live) he/she will work on it.

If no one assigned the issue to themself, then it may have been overlooked, in that case it makes sense to ask on the mail list (new issues should be given 2 or 3 weeks to be seen, even though often it goes faster)
It is possible that even then (after asking on the mail list) you do not get a response. The person may be away for some weeks, or busy otherwise.

-----------------------
This announcement/thread is not going to change this dynamics.

If an issue had been overlooked, then yes you should mention it, but it may well be that if it get picked up now, it will not have a fix in time and them may be pushed to 2.0.4.
Of course if the issue is easy enough to fix, then it may still get done in time.

However in the past we also had cases in which issues were fixed. But it had been forgotten to put them on the merge list.
Or available patches had not been reviewed.
In this cases it has happened that an available fix missed the release for no good reason. We are trying to minimize this. (Of course any other improvement that can reasonably be made for the release would be welcome too)
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: VTwin on April 05, 2019, 06:57:34 pm
Quick reminder:
...
And when that team member has spare free time (between his job and personal live) he/she will work on it.
...
The person may be away for some weeks, or busy otherwise.
...
This announcement/thread is not going to change this dynamics.
...

Thanks, I totally get it. I just figured I'd mention it here as feedback was requested.

For the record, the Cocoa IDE is in extremely good shape. I use it almost every day, and very much appreciate the rapid improvements that have been made. I rarely use the Carbon IDE anymore.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: PeterX on April 05, 2019, 09:00:55 pm
This is not related to Lazarus 2.0.2 release but I answer here anyway ...
Did you test the patch uploaded by Ondrej? Does it help?
I will test this tonight. And then report.

Recompiled IDE .. and yes, it helps.
I can confirm that - with these changes in sourcefilemanager.pas - the MainForm and its component sizes appear correcty.
And not scaled to  (in my case ..) 125%    (but DesignTime MainForm is still at wrong position on screen, also 125% larger values  .TOP and .LEFT)

If it does, can you improve it so a project would not get saved always?

This is more difficult. I can try next week.
But  sourcefilemanager.pas and related units are a lot of code to read and understand ..
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Pascal on April 06, 2019, 10:24:31 am
If possible add r60687 #35230 (https://bugs.freepascal.org/view.php?id=35230)
Needed for LazProfiler to work correctly.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: mattias on April 10, 2019, 01:27:25 pm
I merged 60906.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: JuhaManninen on April 10, 2019, 01:43:42 pm
This is more difficult. I can try next week.
But  sourcefilemanager.pas and related units are a lot of code to read and understand ..
Yes they are! :-)
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Pascal on April 10, 2019, 08:48:50 pm
I merged 60906.
Thanks!
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Akira1364 on April 11, 2019, 12:02:27 am
Regarding the docs thing people had been talking about earlier, is there interest in having them built more often? I do it myself quite often (on Windows, actually, with TexLive and Git Bash) and don't find it very difficult or time consuming, so I'd be happy to volunteer in that regard.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: lucamar on April 11, 2019, 12:08:09 am
Regarding the docs thing people had been talking about earlier, is there interest in having them built more often? I do it myself quite often (on Windows, actually, with TexLive and Git Bash) and don't find it very difficult or time consuming, so I'd be happy to volunteer in that regard.

I am very interested! At least the chms. For some strange reason I've never been able to build them right; there is always some problem or other with the tools that prevent them from being built right :(

Then I come to the forum, comment that something is or isn't on the docs and someone replies: "that has been corrected, look in such or such place"
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Akira1364 on April 11, 2019, 05:31:45 am
I am very interested! At least the chms.

I did a fresh build of the CHMs and made a zip with the same files the release one comes with:

https://www.dropbox.com/s/pkhesdny4nvteco/doc-chm-fpc3.3.1-laz2.1.zip?dl=0 (https://www.dropbox.com/s/pkhesdny4nvteco/doc-chm-fpc3.3.1-laz2.1.zip?dl=0)

Note that the above is based on trunk everything (i.e. the FPC sources and Lazarus sources scanned for the docs were themselves the latest SVN revisions, not just the doc content files.)
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 11, 2019, 06:14:45 am
I am very interested! At least the chms.

I did a fresh build of the CHMs and made a zip with the same files the release one comes with:

https://drive.google.com/open?id=1hbCR6zhPsfVLBC7K--Y0IFUrbW4YQH11 (https://drive.google.com/open?id=1hbCR6zhPsfVLBC7K--Y0IFUrbW4YQH11)

Note that the above is based on trunk everything (i.e. the FPC sources and Lazarus sources scanned for the docs were themselves the latest SVN revisions, not just the doc content files.)

Would you mind sharing the steps you used to generate the chms? I've been stumbling around trying to do the same with the updated fpdoc xml files. No luck so far...
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: wp on April 11, 2019, 10:39:31 am
I create Lazarus chm files by the script "build_chm" in folder "docs/html" - I'm on Windows, therefore, I use "build_chm.bat". These things must be done frist for this to work:
- Load "build_lcl_docs.lpi" into Lazarus and compile it.
- Modify the line "PATH=..." of the script to point the PATH variable to the folder which contains fpdoc.exe (this should be the same as fpc.exe).
- Add "--fpcdocs ../chm" to the "build_lcl_docs" command line so that the created chm files are copied to the right folder automatically. Otherwise the chm files (and xct crossreference files) will appear in the folder of the script, i.e. in "docs/html" and must be copied manually.

This is the script, which is working for me:
Code: [Select]
PATH=C:\lazarus-trunk_fpc304\fpc\3.0.4\bin\i386-win32\;%PATH%
build_lcl_docs.exe --outfmt chm --fpcdocs ../chm

Note that the script aborts when the xml files contain an error. The xml files before r60922, for example, contained an xml error in lazunicode.xml (line 245, the "<>" in "Length(fCurrent)<>aCount." had to be replaced by "&lt;&gt;")

Note also that build_lcl_docs does not add "private" docs to the chm. (There is an option for fpdoc to include the "private" section, but I did not find a way how to invoke this in build_lcl).

Building the Lazarus help takes a few minutes, therefore, be patient.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: lucamar on April 11, 2019, 12:21:51 pm
I did a fresh build of the CHMs and made a zip with the same files the release one comes with:

Lots of thanks, Akira.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Akira1364 on April 11, 2019, 02:50:36 pm
Lots of thanks, Akira.

No problem!

Gotta say though, every time I run fpDoc in general I end up thinking it really kinda needs some work... compared to PasDoc there's a lot of code it either can't parse or doesn't handle properly, or at least handles in a way that looks strange / incomplete output-wise.

Additionally, lots of stuff that appears as totally undocumented in fpDoc-generated docs (due to there being no external XML file for them) actually have useful existing source comments that would serve as definitely-better-than-nothing documentation if fpDoc didn't just ignore them.

Might take a look at seeing if I can fix some of it in the next little while.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 11, 2019, 05:46:14 pm
I create Lazarus chm files by the script "build_chm" in folder "docs/html" - I'm on Windows, therefore, I use "build_chm.bat". These things must be done frist for this to work:
- Load "build_lcl_docs.lpi" into Lazarus and compile it.
- Modify the line "PATH=..." of the script to point the PATH variable to the folder which contains fpdoc.exe (this should be the same as fpc.exe).
- Add "--fpcdocs ../chm" to the "build_lcl_docs" command line so that the created chm files are copied to the right folder automatically. Otherwise the chm files (and xct crossreference files) will appear in the folder of the script, i.e. in "docs/html" and must be copied manually.

This is the script, which is working for me:
Code: [Select]
PATH=C:\lazarus-trunk_fpc304\fpc\3.0.4\bin\i386-win32\;%PATH%
build_lcl_docs.exe --outfmt chm --fpcdocs ../chm

Note that the script aborts when the xml files contain an error. The xml files before r60922, for example, contained an xml error in lazunicode.xml (line 245, the "<>" in "Length(fCurrent)<>aCount." had to be replaced by "&lt;&gt;")

Note also that build_lcl_docs does not add "private" docs to the chm. (There is an option for fpdoc to include the "private" section, but I did not find a way how to invoke this in build_lcl).

Building the Lazarus help takes a few minutes, therefore, be patient.

Thanks @wp. I'll give that a try this weekend.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 11, 2019, 07:05:51 pm
This is the script, which is working for me:
Code: [Select]
PATH=C:\lazarus-trunk_fpc304\fpc\3.0.4\bin\i386-win32\;%PATH%
build_lcl_docs.exe --outfmt chm --fpcdocs ../chm

Note also that build_lcl_docs does not add "private" docs to the chm. (There is an option for fpdoc to include the "private" section, but I did not find a way how to invoke this in build_lcl).

Building the Lazarus help takes a few minutes, therefore, be patient.

According the help screen in build_lcl_docs.lpr, you can use --arg to pass arguments to fpdoc. I think it has to be passed to build_lcl_docs.lpr using the --arg "show-private=true" switch. Not sure about the formatting though until I try it. It seems like it would be a lot simpler to just use an fpdoc project file. But that's just me.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: PeterX on April 11, 2019, 08:34:21 pm
Did you test the patch uploaded by Ondrej? Does it help? If it does, can you improve it so a project would not get saved always?
I don't know why Your project gets saved always, with this patch.
The files of my project only get saved when I change something (I'm on Windows).

If DsgControl.DesignTimePPI = Screen.PixelsPerInch then no file is saved on close,
in case I didn't edit anything. I can open, close, open, close .. nothing's saved.

But indeed, when  DsgControl.DesignTimePPI <> Screen.PixelsPerInch
(when project opened the first time under a different scaling % ..)
then the lfm file must be saved because (for example, in my case ..)
Code: Pascal  [Select]
  1.   DesignTimePPI = 120
in the lfm file must be removed ..
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Akira1364 on April 11, 2019, 09:05:03 pm
Would you mind sharing the steps you used to generate the chms? I've been stumbling around trying to do the same with the updated fpdoc xml files. No luck so far...

To put it as simply as possible (again, I'm on Windows):

-Install TexLive
-Ensure that the main TexLive bin directory (with like a million DLLs and executables) is in your path
-Ensure that the FPC bin directory is also in your path
-Install Git for Windows
-From an elevated git-bash.exe command prompt, change directories to where you've checked out the fpcdocs SVN
-Assuming the "fpcdocs" folder is side-by-side with your "fpcsrc" folder, do:
Code: [Select]
mkdir ./tmp && cp ./fpdoc.cst ./fpdoc.css && make all FPCDIR="../fpcsrc" FPCSRCDIR="../fpcsrc" HTMLFMT=chm CSSFILE="./fpdoc.css" && ./fixdocs.sh-Hope that it works!

I might be forgetting something, but that's the gist of it. There might also have been a couple of FPC sources I actually had to modify in some way and rebuild beforehand to make them not-just-for-Linux, but I can't remember at the moment. I'll check tonight.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 11, 2019, 09:16:26 pm
Would you mind sharing the steps you used to generate the chms? I've been stumbling around trying to do the same with the updated fpdoc xml files. No luck so far...

To put it as simply as possible (again, I'm on Windows):

-Install TexLive
-Ensure that the main TexLive bin directory (with like a million DLLs and executables) is in your path
-Ensure that the FPC bin directory is also in your path
-Install Git for Windows
-From an elevated git-bash.exe command prompt, change directories to where you've checked out the fpcdocs SVN
-Assuming the "fpcdocs" folder is side-by-side with your "fpcsrc" folder, do:
Code: [Select]
mkdir ./tmp && cp ./fpdoc.cst ./fpdoc.css && make all FPCDIR="../fpcsrc" FPCSRCDIR="../fpcsrc" HTMLFMT=chm CSSFILE="./fpdoc.css" && ./fixdocs.sh-Hope that it works!

I might be forgetting something, but that's the gist of it. There might also have been a couple of FPC sources I actually had to modify in some way and rebuild beforehand to make them not-just-for-Linux, but I can't remember at the moment. I'll check tonight.

Thanks for that. But I was mainly interested in LCL and LazUtils - which you covered earlier.

Not going near anything that involves LateX. ;)
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: lucamar on April 11, 2019, 09:24:14 pm
Not going near anything that involves LateX. ;)

Yeah, LateX is for masochist (pun intended :D ) *


* Not intended to be taken seriously! :)
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: wp on April 11, 2019, 10:44:49 pm
According the help screen in build_lcl_docs.lpr, you can use --arg to pass arguments to fpdoc. I think it has to be passed to build_lcl_docs.lpr using the --arg "show-private=true" switch. Not sure about the formatting though until I try it.
Yes, any idea would be appreciated, no matter how I write it I always get "Ignoring unknown option..."

It seems like it would be a lot simpler to just use an fpdoc project file.
I don't know. Yes with fpdoc you have better control of the parameters, but you must write every parameter in an xml project file which otherwise is correctly set by build_lcl_docs. Well, at least now I have a working fpdoc project for TAChart which I uploaded today (folder (lazarus trunk)/components/tachart/fpdpc/chm).
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Akira1364 on April 11, 2019, 11:01:06 pm
Thanks for that. But I was mainly interested in LCL and LazUtils - which you covered earlier.

Well, that was WP who did the other comment about how exactly they build LCL docs actually.

It is unfortunate that the build process is so dependent on LaTeX stuff, though... specifically you can't properly generate the CHM or normal HTML versions of the reference manual, users manual, programmers manual, or fpdoc manual without first building the PDF versions.

I don't think it being in LaTex really pays off enough to make it worth it in the end, either. All of the diagrams used are premade PNGs anyways, for example...
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 12, 2019, 12:52:55 am
LCL and LazUtils online (SourceForge) are at version 0.9.3.

That has been remedied.
FPC => 3.0.4
Lazarus => trunk
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 12, 2019, 01:17:54 am
LCL and LazUtils online (SourceForge) are at version 0.9.3.

That has been remedied.
FPC => 3.0.4
Lazarus => trunk

Thank you.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Wallaby on April 14, 2019, 03:14:20 am
Please merge 60963, 60962, 60952, 60951, 60950, 60949 to fixes 2_0. These fix a number of issues with Cocoa.

Quote
cocoa: shrink focus rect by one pixel from far sides
cocoa: update the focused item status of a table raw. Only show it as focused, if it's selected and the control itself is focused. #32051
cocoa: adding detection if a combobox is showing a popup window
cocoa: adding track area of readonly items, so they can be refreshed automatically as mouse moves around
cocoa: do not call DrawItem for readonly dropdown if no item is not selected. #21791
cocoa: support for using DrawItem when drawing a read-only combobox. #21791
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 14, 2019, 03:27:07 am
We can look at them for 2.0.4.  Building for 2.0.2 started yesterday (Saturday) morning.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: VTwin on April 14, 2019, 03:49:18 pm
Not going near anything that involves LateX. ;)

Yeah, LateX is for masochist (pun intended :D ) *


* Not intended to be taken seriously! :)

and when you Goggle for help you need to make sure "Safe Search" is on!  ;)
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 15, 2019, 07:28:53 am
Lazarus 2.0.2 appeared on the resource http://mirrors.iwi.me/lazarus/   :)
I have already installed on Windows 10 x64.
But I can not rebuild IDE. Rebuild ends with an error "Fatal: Unable to open file C:UsersUserAppDataLocallazarusidemake.cfg -dx86_64".
Could someone explain what could be wrong?

Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 15, 2019, 01:07:22 pm
Maybe something in your local config... It rebuilds fine for me.

Btw, are there really no backslashes in the path? Or did that happen copy and paste?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 15, 2019, 06:49:53 pm
Maybe something in your local config... It rebuilds fine for me.

Btw, are there really no backslashes in the path? Or did that happen copy and paste?

I tried it with an export of trunk. There are no directory separators in the file name on Win 8.1.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 15, 2019, 07:28:46 pm
What if you start with an empty config?

lazarus.exe --primary-config-path=C:\empty_dir
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 15, 2019, 07:36:08 pm
Btw, are there really no backslashes in the path? Or did that happen copy and paste?
This is not a copy / paste error. There are really no separators.

What if you start with an empty config?
Thanks for the advice. But I tried to delete all settings (AppData\Local\lazarus). Made a clean install. Does not help.
In the environment variables found nothing suspicious.
But on Windows 7 x64 everything works fine!
I do not know the reasons yet.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 15, 2019, 07:53:18 pm
Please report as a bug.  Someone who knows the build system better than me will have to take a look.

Just in case: Run the IDE with --debug-log=C:\logfile.txt  and attach the file. (Including attempt to rebuild)

After the failed build, right click the messages window and from the popup menu select: Copy > All/Original messages
Save to a file and attach

Also open menu: View > IDE Internals > About IDE
and copy the content of the "general" tab.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 15, 2019, 08:59:47 pm
Please report as a bug.
OK. I reported a bug. The number is 0035384.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 15, 2019, 10:16:05 pm
Could it be, that you have another "make.exe" in your path?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 15, 2019, 10:54:21 pm
Could it be, that you have another "make.exe" in your path?

Not in my case, on Win 8.1.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 16, 2019, 03:52:12 pm
From the logs on the issue, this is the command that fails
Code: [Select]
C:/lazarus/fpc/3.0.4/bin/x86_64-win64/fpc.exe -gl -vbqewnhi -Sci -dlclwin32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuinclude/win -Fuframes -Fu. -Fiinclude -Fiinclude/win64 -Fi../images -FE.. -FU../units/x86_64-win64/win32 -WG "@C:\Users\User\AppData\Local\lazarus\idemake.cfg" -dx86_64 lazarus.pp
Is your user-account called "User"?

The backslash are still in place. And it is the same command that my IDE goes through (only I do not get the error).

"my IDE" here refers to the installation I made with the official installer as it comes from sourceforge.
That means I have the same fpc. We should both have the same "make.exe"

Leaves the question if there is a diff in the OS.
I don't yet have the current Windows Update installed. So no idea if that will change anything.
(Does 2.0.0 still work/rebuild on your PC?)

According to the logfile, it looks like fpc tries to access the file:
Code: [Select]
@C:UsersUserAppDataLocallazarusidemake.cfg -dx86_64Fpc must have seen the @, because that makes it tread this as a file to be read.
Though it could have thought this is the file to compile, yet then I would have expected a warning that more than one file was specified...

At what time the " and \ were removed, is unclear. But I guess something went bad with the quoting, because it joined the next argument to the current.

Can you open a cmd.exe
And then run the above command from there?

If it fails at -va
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 16, 2019, 05:40:35 pm
Is your user-account is called "User"?
(Does 2.0.0 still work/rebuild on your PC?)
Can you open a cmd.exe
And then run the above command from there?
If it fails at -va
Yes, user-account called "User".
And the command completed without error.
The checksum of the installation files is correct.
I checked rebuild Lazarus 2.0.0. No errors on this version.

Code: [Select]
c:\lazarus\ide>C:/lazarus/fpc/3.0.4/bin/x86_64-win64/fpc.exe -gl -vbqewnhi -Sci -dlclwin32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuinclude/win -Fuframes -Fu. -Fiinclude -Fiinclude/win64 -Fi../images -FE.. -FU../units/x86_64-win64/win32 -WG "@C:\Users\User\AppData\Local\lazarus\idemake.cfg" -dx86_64 lazarus.pp
Hint: (11030) Start of reading config file C:\lazarus\fpc\3.0.4\bin\x86_64-win64\fpc.cfg
Hint: (11031) End of reading config file C:\lazarus\fpc\3.0.4\bin\x86_64-win64\fpc.cfg
Hint: (11030) Start of reading config file C:\Users\User\AppData\Local\lazarus\idemake.cfg
Hint: (11031) End of reading config file C:\Users\User\AppData\Local\lazarus\idemake.cfg
Free Pascal Compiler version 3.0.4 [2019/04/13] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
(1002) Target OS: Win64 for x64
(3104) Compiling lazarus.pp
c:\lazarus\ide\lazarus.pp(115,20) Warning: (5044) Symbol "MainFormOnTaskBar" is not portable
(9022) Compiling resource C:\lazarus\units\x86_64-win64\win32\lazarus.obj
(9015) Linking ..\lazarus.exe
(1008) 261 lines compiled, 8.0 sec, 14273984 bytes code, 875044 bytes data
(1021) 1 warning(s) issued
(1022) 4 hint(s) issued
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 16, 2019, 07:14:08 pm
A mystery....

The command in the makefile appears correct. (and should be the same for 2.0.0 and 2.0.2 => pretty sure that has not changed in a while)
The command runs outside the makefile.

Also 2.0.0 should have the same version of make. But to be sure, can you check?
Make.exe is in the fpc/3.0.4/x86...../bin directory in each Lazarus installation.
Run: make.exe -version

I get: GNU Make 3.80
for 2.0.2 and 2.0.0

The Makefile in both directories (ide) also is the same on my installs.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 16, 2019, 08:33:49 pm
Run: make.exe -version

I get: GNU Make 3.80
for 2.0.2 and 2.0.0

An interesting situation. Perhaps an error in the causes close to this.
I have installed MinGW. Make from the MinGW is registered in my path variable. By default "make.exe -version" show 3.81.
I have prescribed the path "C:\lazarus\fpc\3.0.4\bin\x86_64-win64" above the others.
Then "make.exe -version" show 3.80. But the error remained.
I can’t completely delete all the "path" to make. This is likely to make inoperable many programs (Altera Quartus Prime, Atollic TrueStudio, etc).

Sorry for my English. If I wrote something is not clear, I will try to reformulate.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: lucamar on April 16, 2019, 08:39:31 pm
Version 3.81 should work just as well as 3.80, provided both are "GNU make".

In fact, "3.81" is the version of make used in this Linux box.

The problems arise when there is a "make" in the path which is not "GNU make", like for example the Borland make.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: creaothceann on April 16, 2019, 09:37:30 pm
I can’t completely delete all the "path" to make. This is likely to make inoperable many programs (Altera Quartus Prime, Atollic TrueStudio, etc).

The PATH variable is a variable for a reason. You can change it with the set command and run your program, then change it back, leave it as is, or simply close your command-line interpreter. In a batch file you can use the setlocal command to make sure that the environment variables are restored.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 16, 2019, 09:43:08 pm
Probably, I found where the cause of the bug.
In the environment variable "Path" I have the values "c:\MinGW\MSYS\1.0\bin" and "C:\msys64\usr\bin".
If "c:\MinGW\MSYS\1.0\bin" is above "C:\msys64\usr\bin", then the bug manifests, otherwise it does not.
But in version 2.0.0 and below this bug was missing. Therefore, I believe that this can be considered an error in version 2.0.2, and not an error in the system.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: ASBzone on April 16, 2019, 10:40:23 pm
But in version 2.0.0 and below this bug was missing. Therefore, I believe that this can be considered an error in version 2.0.2, and not an error in the system.

Are you saying that you installed 2.0 after you had already installed both of these versions of MinGW?

From the description of the problem with the path, it appears that you have installed the x64 version of Lazarus.  Were your earlier versions of Lazarus also 64-bit, or rather 32-bit?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dbannon on April 17, 2019, 01:44:03 am
I guess its too late to say that there is a memory leak in TBitBnt in Cocoa ?

(Sorry, just spotted it,  https://bugs.freepascal.org/view.php?id=35400 )

(I'm going to open another forum thread under Mac 'cos there are other things related)

Davo
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: dsiders on April 17, 2019, 01:55:38 am
Probably, I found where the cause of the bug.
In the environment variable "Path" I have the values "c:\MinGW\MSYS\1.0\bin" and "C:\msys64\usr\bin".
If "c:\MinGW\MSYS\1.0\bin" is above "C:\msys64\usr\bin", then the bug manifests, otherwise it does not.
But in version 2.0.0 and below this bug was missing. Therefore, I believe that this can be considered an error in version 2.0.2, and not an error in the system.

In my case, it wasn't make.exe. It was something else in the Cygwin environment. Removing cygwin from my path allowed it to build successfully. And no, it was not make.exe- there wasn't one in Cygwin. I haven't pinpointed the exact cause yet. But removing Cygwin was enough.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 17, 2019, 07:31:28 am
Are you saying that you installed 2.0 after you had already installed both of these versions of MinGW?
Yes it is.

Were your earlier versions of Lazarus also 64-bit, or rather 32-bit?
All previous versions on this system were also x64.

In my case, it wasn't make.exe. It was something else in the Cygwin environment. Removing cygwin from my path allowed it to build successfully. And no, it was not make.exe- there wasn't one in Cygwin. I haven't pinpointed the exact cause yet. But removing Cygwin was enough.
It seems that on my system the cause was not make.exe. Just like you.
When I set the "clear all" option when reassembling, in the message window I often saw "c:/msys64/usr/bin/rm.exe ...".
That is, Lazarus version 2.0.2 prefers to use the utilities from the Path environment, rather than those used in its distribution. The use of "/" instead of the "\" is also surprising. But this does not cause an error.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Thaddy on April 17, 2019, 07:53:42 am
The use of "/" instead of the "\" is also surprising. But this does not cause an error.
The majority of platforms supported by FPC use / as path separator.  Furthermore it is transparent: both / and \ can be used.
\ is a windows/dos centric path separator.
You should not be surprised at all  :D
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 17, 2019, 08:16:48 am
You should not be surprised at all  :D
I considered that the "/" is used only for Unix-like systems. Windows usually uses a backslash. But it seems that the "/" also works well for Windows.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 17, 2019, 01:53:22 pm
Could either of you test the following patch (with your original environment)?
Applies only if you build from within the IDE. If you use commandline (make/lazbuild) you need to adapt the path yourself.

Alternatively download the f-ide-build branch from
https://github.com/User4martin/lazarus/tree/f-ide-build

Code: [Select]
ide/buildlazdialog.pas | 13 +++++++++++--
diff --git a/ide/buildlazdialog.pas b/ide/buildlazdialog.pas
index 3b560fb937..5c3e562fec 100644
--- a/ide/buildlazdialog.pas
+++ b/ide/buildlazdialog.pas
@@ -58,7 +58,7 @@ uses
   CodeToolManager, DefineTemplates,
   // IDEIntf
   LazIDEIntf, IDEMsgIntf, IDEHelpIntf, IDEImagesIntf, IDEWindowIntf, IDEDialogs,
-  PackageIntf, IDEExternToolIntf,
+  PackageIntf, IDEExternToolIntf, BaseIDEIntf,
   // IDE
   LazarusIDEStrConsts, TransferMacros, LazConf, DialogProcs,
   MainBar, EnvironmentOpts,
@@ -419,6 +419,9 @@ var
   IdeBuildMode: TIdeBuildMode;
   s: String;
   DefaultTargetFilename: String;
+  {$IFDEF WINDOWS}
+  env: TStringList;
+  {$ENDIF}
 begin
   // Get target files and directories.
   Result:=mrCancel;
@@ -437,8 +440,14 @@ begin
     EnvironmentOverrides.Values['LCL_PLATFORM']:=LCLPlatformDirNames[Profile.TargetPlatform];
     EnvironmentOverrides.Values['LANG']:= 'en_US';
     s:=EnvironmentOptions.GetParsedCompilerFilename;
-    if s<>'' then
+    if s<>'' then begin
       EnvironmentOverrides.Values['PP']:=s;
+      {$IFDEF WINDOWS}
+      env := EnvironmentAsStringList;
+      EnvironmentOverrides.Values['PATH']:= ExtractFileDir(s) + ';' + env.Values['PATH'];
+      env.Free;
+      {$ENDIF}
+    end;
 
     Executable:=EnvironmentOptions.GetParsedMakeFilename;
     if (Executable<>'') and (not FileExistsUTF8(Executable)) then
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 17, 2019, 03:06:32 pm
Could either of you test the following patch (with your original environment)?
Unfortunately, your patch did not fix the bug. I got the same error: "Fatal: Unable to open file C:UsersUserAppDataLocallazarusidemake.cfg -dx86_64".
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 17, 2019, 07:46:03 pm
In seems that make (the make in fpc) looks for an sh.exe (or maybe other shells). Findind one, it will use it, and that screws the build process.

No idea how to prevent it.

It may be able to force it to use cmd.exe, but that is ridiculously slow.
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 19, 2019, 04:57:08 pm
I made a fake sh.exe in the "c:\MinGW\msys\1.0\bin\" folder. It writes the received parameters to the file (ParamStr(0) .. ParamStr(ParamCount)). This is what he gets when rebuilding Lazarus 2.0.2.
Code: [Select]
c:\MinGW\MSYS\1.0\bi\sh.exe -c C:/lazarus/fpc/3.0.4/bin/x86_64-win64/fpc.exe -gl -vbqewnhi -Sci -dlclwin32 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuinclude/win -Fuframes -Fu. -Fiinclude -Fiinclude/win64 -Fi../images -FE.. -FU../units/x86_64-win64/win32 -WG \@C:\Users\User\AppData\Local\lazarus\idemake.cfg\ -dx86_64 lazarus.pp
Version 2.0.0 does not use sh.exe at all. Any idea why version 2.0.2 uses sh.exe? And why do double quotes become backslashes?
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: Martin_fr on April 19, 2019, 05:14:40 pm
It is something that make does. You can specify a shell to make
make target SHELL=...

But that does not help. According to my tests, if it does not find one, then it uses a build in shell (or so it seems). But I found no way to force that.

You can give it cmd.exe. But that is dead slow.


Check the makefile, there is one target that just echos all sorts of info "make fpc_...info". You can use that to play around.

I did not found any real solution.

One could put a shell into the fpc folder, and then use the patch to add that to the start of the PATH. Then the shell provided by lazarus would be used.
It would still be an external shell, not the builtin. And could be a problem. This is called on many different versions of windows, with all sort of different other settings..... Who knows if or what it may break.

Also some people may have fpc in their path. So ia fake shell could be disastrous. Because while it might work for the make scenario, it would break probably anything else that would use it as a shell.

In any case, I am not the expert on the whole make business. If this topic stands a chance of getting attention then probably on the mail list. So if interested, I suggest to try there, and see if anyone else from the team wants to take this on. If they believe a fake shell is not as risky as I assumed, then maybe someone is willing to go that path.

As I said, unfortunately not my area of expertise. So I am opting out. (unless make can be given an argument to force it to the internal shell)
Title: Re: We are planning the next release: Lazarus 2.0.2
Post by: yurix on April 19, 2019, 06:18:16 pm
So I am opting out. (unless make can be given an argument to force it to the internal shell)
Anyway, thanks for your help. Removing a shell from a path is in most cases an acceptable solution. I think this solution can be advised to those who face a similar problem.
Maybe one day the cause of the problem will be found.