From nc-gaertnma at netcologne.de  Thu Dec  1 23:00:44 2022
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Thu, 1 Dec 2022 23:00:44 +0100
Subject: [Lazarus] Makefile issues
In-Reply-To: <alpine.DEB.2.22.394.2211301208350.547235@home>
References: <alpine.DEB.2.22.394.2211301208350.547235@home>
Message-ID: <20221201230044.2ea0a10d@limapholos>

On Wed, 30 Nov 2022 14:35:24 +0100 (CET)
Michael Van Canneyt via lazarus <lazarus at lists.lazarus-ide.org> wrote:

> Hello,
> 
> The lazarus makefile has some dependency issues.
> 
> make ide:

That's an internal target.
See "make help".

 
>[...]
> Based on the output of "make help", in an attempt to create
> svn2revisioninc I did:
> 
> > make tools  
> make -C tools
> make[1]: Entering directory '/home/michael/projects/lazarus-tst/tools'
> Makefile:2956: warning: overriding recipe for target '.'
> Makefile:2954: warning: ignoring old recipe for target '.'
> make --assume-new=lazres.pp lazres
> make[2]: Entering directory '/home/michael/projects/lazarus-tst/tools'
> Makefile:2956: warning: overriding recipe for target '.'
> Makefile:2954: warning: ignoring old recipe for target '.'
> /usr/local/bin/ppcx64 -gl -Fu.
> -Fu../components/lazutils/lib/x86_64-linux
> -Fu../lcl/units/x86_64-linux -Fu../lcl/units/x86_64-linux/nogui
> -Fu/usr/local/lib/fpc/3.3.1/units/x86_64-linux/rtl -FE. -FU. -Cg
> -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -Flinclude
> -Fl/etc/ld.so.conf.d/*.conf -dx86_64 lazres.pp lazres.pp(43,22)
> Fatal: Can't find unit LazLogger used by LazRes

Sub target "tools" require a compiled nogui lcl.
Just use the main targets.

The makefiles are not supposed to be called in any order. They are
merely a bootstrap to get to lazbuild and/or lazarus.


>[...]
> > make basecomponents  

Same here.

>[...]
> After some more failed attempts trying to compile "sub-targets", I
> gave up.

Good.

 
> Am I correct in my understanding that in fact only the "main" targets
> all, bigide, useride are supposed to work out of the box when you
> start from a fresh checkout ?

Yes.

Mattias

From michael at freepascal.org  Thu Dec  1 23:22:38 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Thu, 1 Dec 2022 23:22:38 +0100 (CET)
Subject: [Lazarus] Makefile issues
In-Reply-To: <20221201230044.2ea0a10d@limapholos>
References: <alpine.DEB.2.22.394.2211301208350.547235@home>
 <20221201230044.2ea0a10d@limapholos>
Message-ID: <alpine.DEB.2.22.394.2212012316350.702966@home>



On Thu, 1 Dec 2022, Mattias Gaertner via lazarus wrote:

> On Wed, 30 Nov 2022 14:35:24 +0100 (CET)
> Michael Van Canneyt via lazarus <lazarus at lists.lazarus-ide.org> wrote:
>
>> Hello,
>>
>> The lazarus makefile has some dependency issues.
>>
>> make ide:
>
> That's an internal target.
> See "make help".
>
>> Am I correct in my understanding that in fact only the "main" targets
>> all, bigide, useride are supposed to work out of the box when you
>> start from a fresh checkout ?
>
> Yes.

Well, it turns out that "make useride" also does not work on a fresh
checkout. At least, I could no longer get it to work.

see my comment in
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40024

But the point of the 'main targets' is taken, so I filed a feature 
request in the issue tracker to be able to build the LCL using just 
the Makefile.

basically, I would like something as

make lcl

to produce the LCL units.

(it can be another 'main' target name if that is needed, obviously)

Michael.

From nc-gaertnma at netcologne.de  Fri Dec  2 00:10:25 2022
From: nc-gaertnma at netcologne.de (Mattias Gaertner)
Date: Fri, 2 Dec 2022 00:10:25 +0100
Subject: [Lazarus] Makefile issues
In-Reply-To: <alpine.DEB.2.22.394.2212012316350.702966@home>
References: <alpine.DEB.2.22.394.2211301208350.547235@home>
 <20221201230044.2ea0a10d@limapholos>
 <alpine.DEB.2.22.394.2212012316350.702966@home>
Message-ID: <20221202001025.02a32124@limapholos>

On Thu, 1 Dec 2022 23:22:38 +0100 (CET)
Michael Van Canneyt via lazarus <lazarus at lists.lazarus-ide.org> wrote:

>[...]
> Well, it turns out that "make useride" also does not work on a fresh
> checkout.

It didn't work when Cleaning is enabled. Fixed.


>[...]
> But the point of the 'main targets' is taken, so I filed a feature 
> request in the issue tracker to be able to build the LCL using just 
> the Makefile.
> 
> basically, I would like something as
> 
> make lcl
> 
> to produce the LCL units.

make registration lazutils lcl

The problem is that make is pretty dumb, so it creates only a
rudimentary Makefile.compiled file.
If you use lazbuild or lazarus to compile a project they might decide
to recompile the lcl.
It would be safer to compile lazbuild, and then use that to
compile the lcl.


Mattias

From michael at freepascal.org  Fri Dec  2 00:45:09 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Fri, 2 Dec 2022 00:45:09 +0100 (CET)
Subject: [Lazarus] Makefile issues
In-Reply-To: <20221202001025.02a32124@limapholos>
References: <alpine.DEB.2.22.394.2211301208350.547235@home>
 <20221201230044.2ea0a10d@limapholos>
 <alpine.DEB.2.22.394.2212012316350.702966@home>
 <20221202001025.02a32124@limapholos>
Message-ID: <alpine.DEB.2.22.394.2212020028080.722082@home>



On Fri, 2 Dec 2022, Mattias Gaertner via lazarus wrote:

> On Thu, 1 Dec 2022 23:22:38 +0100 (CET)
> Michael Van Canneyt via lazarus <lazarus at lists.lazarus-ide.org> wrote:
>
>> [...]
>> Well, it turns out that "make useride" also does not work on a fresh
>> checkout.
>
> It didn't work when Cleaning is enabled. Fixed.
>
>
>> [...]
>> But the point of the 'main targets' is taken, so I filed a feature
>> request in the issue tracker to be able to build the LCL using just
>> the Makefile.
>>
>> basically, I would like something as
>>
>> make lcl
>>
>> to produce the LCL units.
>
> make registration lazutils lcl

Slightly better is:

make -J N registration
make -J N lazutils
make -J N lcl

because the order as specified on the command-line is not guaranteed when you do parallel compilation.

Still, it feels strange to me that

make lcl

is not enough, but OK.

> The problem is that make is pretty dumb, so it creates only a
> rudimentary Makefile.compiled file.

Makefile.compiled does not even come into play, see below.

> If you use lazbuild or lazarus to compile a project they might decide
> to recompile the lcl.

That may not happen, because the sources will not be installed on the build machine.

> It would be safer to compile lazbuild, and then use that to
> compile the lcl.

The projects will be compiled with fpc only in a docker environment.
The devops people don't want another build tool. Only make.
(which is why I wanted to have make install working - but I had to resort to
using find and cp manually)

The goal is to have just fpc, its units and the LCL units in compiled form in the docker.

Michael.

From giuliano.colla at fastwebnet.it  Mon Dec  5 12:00:12 2022
From: giuliano.colla at fastwebnet.it (Giuliano Colla)
Date: Mon, 5 Dec 2022 12:00:12 +0100
Subject: [Lazarus] ***SPAM*** Re: ***SPAM*** Re: Install of Qt5
 widgetset fails on Mac Ventura
In-Reply-To: <21e265f9-e833-b31d-97bd-fe130149833c@holobit.hr>
References: <b71394c2-8b76-68dc-1460-bafae4ffd4ce@fastwebnet.it>
 <ada3a558-d566-0527-a110-ef889a23f4e5@holobit.hr>
 <37b2761f-4782-0c9a-2ecb-5258d8f9622c@fastwebnet.it>
 <191f9237-6a43-ea0b-e7ea-e53b12365f08@holobit.hr>
 <dcc87cbe-1c24-3825-a477-63b07698fcd1@fastwebnet.it>
 <21e265f9-e833-b31d-97bd-fe130149833c@holobit.hr>
Message-ID: <3ec11940-8690-2507-5887-e9d73ddcca5a@fastwebnet.it>



Il 28/11/2022 08:18, zeljko ha scritto:
>
>
> On 27. 11. 2022. 23:47, Giuliano Colla wrote:
>> Il 26/11/22 09:20, zeljko ha scritto:
>>
>>>
>>>
>>> On 25. 11. 2022. 23:01, Giuliano Colla wrote:
>>>> Il 25/11/2022 21:58, zeljko ha scritto:
>>>>
>>>>>
>>>>>
>>>>> On 25. 11. 2022. 19:29, Giuliano Colla via lazarus wrote:
>>>>>> I tried to install QT5 version 5.6.2 on my Mac, following the 
>>>>>> wiki instructions but installation fails.
>>>>>>
>>>>>> qmake executes properly and generates a Makefile, but make fails 
>>>>>> with this error message:
>>>>>>
>>>>>> ??ld: symbol(s) not found for architecture arm64
>>>>>> clang: error: linker command failed with exit code 1 (use -v to 
>>>>>> see invocation)
>>>>>> make: *** [Qt5Pas.framework/Qt5Pas] Error 1
>>>>>>
>>>>>> Actally all the object files generated in the tmp directory are 
>>>>>> for arm64 and not x86_64-darwin as expected.
>>>>>>
>>>>>> Any hint?
>>>>>
>>>>> Never tried build on arm64 (have intel macbook pro). Can you try 
>>>>> with Qt6 ?
>>>>>
>>>>> z.
>>>> I didn't find a place from where download open source Qt6. Do you 
>>>> have a reliable link?
>>>
>>> https://download.qt.io/official_releases/online_installers/qt-unified-mac-x64-online.dmg 
>>>
>>>
>>>>
>>>> In the meantime I'll give a try with 5.6.11.
>>>>
>>>> However all Lazarus is compiled for x86_64 architecture, and runs 
>>>> in arm64 architecture via Rosetta. Intel version of Qt would be 
>>>> just fine, if qmake didn't decide to make for the arm64 
>>>> architecture. Any idea of how to tell qmake the right architecture?
>>>
>>> You have to read qmake manual:
>>> https://doc.qt.io/qt-6/qmake-manual.html
>>>
>>> zeljko
>>
>> Two issues:
>>
>> First issue is that it appears that you can't call qmake from command 
>> line.
>>
>> Either there's a bug somewhere on the Mac Ventura, or I'm missing 
>> some detail. I tried to build the Qt5Pas library by submitting 
>> Qt5Pas.pro to Qt Designer. It generated correct x86_64 objects, and 
>> the generated framework contains a:
>>
>> Qt5Pas: Mach-O 64-bit dynamically linked shared library x86_64
>>
>> Just to understand what was going on, I then tried again with the 
>> command line options, passing qmake exactly the same parameters which 
>> Qt Designer used, and the result was the same error as before, with 
>> the tmp folder populated with arm64 object files. It would appear 
>> that qmake ignores the x86_64 switch when called from command line. 
>> If this is confirmed it would be good to update the wiki page.
>>
>> Second issue.
>>
>> Lazarus does not build with Qt. I have set the appropriate symlink in 
>> the /Library/Frameworks folder, but build of Lazarus fails with the 
>> error message:
>>
>> ld: framework not found Qt5Pas
>>
>> I have added /Library/Frameworks to the compiler paths 
>> (-FI/Library/Frameworks). Should I tell something to the linker too?
>
>
> 1. I had problem on intel mac when installed qt6.2 (qt5.15 was already 
> installed) , but make clean and removing .qmake_stash and .qcmake_xx 
> files manually from cbindings directory helped me a lot. So maybe you 
> should remove such files and then start qmake-6 again (for arm).
>
> 2.On newer macs Library/Frameworks is not in path by default, I've 
> found that symlinking Qt5Pas to Library/Frameworks and 
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks 
> fixed problem for make bigide.
>
> 3.You should add "-k -F/Library/Frameworks" to the configure "Build 
> Lazarus" dialog if you want to rebuild lazarus for Qt5, or for your 
> projects in Project Options check "Pass options with linker with "k" 
> ...." -F/Library/Frameworks and then it should work
>
>
> zeljko
Following your guidelines I've been able to build a number of 
Lazarus-Qt5 with different Lazarus versions (2.0.12 - 2.2.4 -2.2.5) but 
the results are disappointing. While all of them work perfectly with 
cocoa WS, Qt5 rises a number of weird issues.
Editor window font treated wrongly in 2.0.12 and 2.2.4 (the font 
displayed is different from the one selected, with font gliphs and font 
spacing not matching), and in all versions weird behaviour of main title 
bar and drop down menus.
The title bar shows the menu entries only if focus is in the main 
Lazarus window, and they disappear if focus is on any other window, and 
the menus are scrambled. Lazarus ->preferences opens "Configure build 
Lazarus", the last line of the submenus is missing, some entries are 
translated, some are not. Most keyboard entries aren't recognized, etc.
Apparently the interaction between Qt bindings and Rosetta, plus a Qt 
version not well supported by Ventura makes a mess.

I've reached the conclusion that the best approach would be to switch to 
a native arm64 build and use Qt6 which is the one supported with M1 
processor. I've rebuilt Lazarus 2.2.4-cocoa in arm64 and everything 
works fine. I've seen in the forum that you're testing Qt6. If you could 
let me have what is required, I could integrate your tests with my test 
on arm64 architecture. Would it be possible?

Thank you,

Giuliano

-- 
Do not do to others as you would have them do to you.They might have different tastes.


From luca at wetron.es  Tue Dec 13 12:53:57 2022
From: luca at wetron.es (Luca Olivetti)
Date: Tue, 13 Dec 2022 12:53:57 +0100
Subject: [Lazarus] Lazreport: how to print something when there are no
 records?
Message-ID: <b46261d5-deed-397f-d323-ddc5c70b1b79@wetron.es>

As per the subject, I'd like LazReport to print "No records to print" 
(or whatever else I want to print) when there are no records in the dataset.
How do I do that?

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007

From luca at wetron.es  Wed Dec 14 17:11:58 2022
From: luca at wetron.es (Luca Olivetti)
Date: Wed, 14 Dec 2022 17:11:58 +0100
Subject: [Lazarus] Lazreport: how to print something when there are no
 records?
In-Reply-To: <b46261d5-deed-397f-d323-ddc5c70b1b79@wetron.es>
References: <b46261d5-deed-397f-d323-ddc5c70b1b79@wetron.es>
Message-ID: <a8eca8f3-a001-bfee-16f4-9835fbcb970e@wetron.es>

El 13/12/22 a les 12:53, Luca Olivetti via lazarus ha escrit:
> As per the subject, I'd like LazReport to print "No records to print" 
> (or whatever else I want to print) when there are no records in the 
> dataset.
> How do I do that?

I found a way: add a record summary band with my text and in the 
OnBeginBand event I set its visible property to false if there are 
records in the dataset.

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007


From ganmax at narod.ru  Thu Dec 15 00:25:22 2022
From: ganmax at narod.ru (Maxim Ganetsky)
Date: Thu, 15 Dec 2022 02:25:22 +0300
Subject: [Lazarus] Attn. Don, documentation snapshots via CI
Message-ID: <c5437356-aa67-d34b-9fe8-663cd8472a4e@narod.ru>

Hello.

As a first step of solving outdated documentation snapshot issue 
(https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40032 ) I 
propose to generate it as an artifact of CI job (in `main` branch for 
now), which then can be uploaded wherever we want.

So I have the following questions:

1. FPDoc from which FPC version is preferred (from `main` branch I guess)?
2. Where rtl.xct and fcl.xct should be obtained? Should FPC 
documentation be built first?
3. Should we build HTML, CHM or both?
4. Are there any dependencies beyond Lazarus, FPC and their sources?

-- 
Best regards,
  Maxim Ganetsky                  mailto:ganmax at narod.ru

From michael at freepascal.org  Thu Dec 15 08:50:35 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Thu, 15 Dec 2022 08:50:35 +0100 (CET)
Subject: [Lazarus] Attn. Don, documentation snapshots via CI
In-Reply-To: <c5437356-aa67-d34b-9fe8-663cd8472a4e@narod.ru>
References: <c5437356-aa67-d34b-9fe8-663cd8472a4e@narod.ru>
Message-ID: <alpine.DEB.2.22.394.2212150847330.361563@home>



On Thu, 15 Dec 2022, Maxim Ganetsky via lazarus wrote:

> Hello.
>
> As a first step of solving outdated documentation snapshot issue 
> (https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40032 ) I propose 
> to generate it as an artifact of CI job (in `main` branch for now), which 
> then can be uploaded wherever we want.
>
> So I have the following questions:
>
> 1. FPDoc from which FPC version is preferred (from `main` branch I guess)?

main.

> 2. Where rtl.xct and fcl.xct should be obtained? Should FPC documentation be 
> built first?

rtl.xct and fcl.xct are generated when the FPC documentation is built.

However, note that the documentation of FPC is only updated after a release.
so if you use FPC main to generate documentation, it will not match what FPC
publishes.

> 3. Should we build HTML, CHM or both?

If it is for upload, then CHM makes no sense to me, but that's up to the
lazarus team, obviously...

Michael.

From fpc at pascalprogramming.org  Thu Dec 15 10:54:13 2022
From: fpc at pascalprogramming.org (Marco van de Voort)
Date: Thu, 15 Dec 2022 10:54:13 +0100
Subject: [Lazarus] Attn. Don, documentation snapshots via CI
In-Reply-To: <alpine.DEB.2.22.394.2212150847330.361563@home>
References: <c5437356-aa67-d34b-9fe8-663cd8472a4e@narod.ru>
 <alpine.DEB.2.22.394.2212150847330.361563@home>
Message-ID: <dcdc5e56-0863-62d8-9693-9f805823a5f9@pascalprogramming.org>


On 15-12-2022 08:50, Michael Van Canneyt via lazarus wrote:
>
>
> If it is for upload, then CHM makes no sense to me, but that's up to the
> lazarus team, obviously...
>
CHM is due to its compression also quite CPU hungry. Generating the LCL 
chm would keep a core occupied for minutes.

I certain think CHM snapshots are worthwhile, for IDE integration, but 
monthly or so is enough.


From alb42 at web.de  Sat Dec 17 17:14:26 2022
From: alb42 at web.de (Marcus Sackrow)
Date: Sat, 17 Dec 2022 17:14:26 +0100
Subject: [Lazarus] LCL compilation fail for at least x86_linux
Message-ID: <202170dd-c9e5-7799-7845-ad90a60c6209@web.de>

Hi,


the LCL compilation fails since b40000c46c16207dc00997df6aeb83f01198787b

for all platforms I let compile in my Jenkins for example x86_64-linux


Compiling ./widgetset/wsforms.pp
customform.inc(38,5) Warning: Case statement does not handle all possible cases
customform.inc(647,3) Note: Local variable "NewState" not used
customform.inc(1164,26) Error: Incompatible types: got "TAnchors" expected "Set Of TAnchorKind"
customform.inc(1168,8) Error: Incompatible types: got "SYSTEM.UITYPES.TAnchorKind" expected "CONTROLS.TAnchorKind"
customform.inc(1170,8) Error: Incompatible types: got "SYSTEM.UITYPES.TAnchorKind" expected "CONTROLS.TAnchorKind"
forms.pp(2345) Fatal: There were 3 errors compiling module, stopping
Fatal: Compilation aborted
make[1]: *** [Makefile:4639: alllclunits.ppu] Error 1
make[1]: Leaving directory '/var/lib/jenkins/workspace/LCL_off_x86_64-linux/lcl'



full log at

https://build.alb42.de:8081/job/LCL_off_x86_64-linux/12105/console


Greetings,

Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20221217/dda56c5c/attachment.htm>

From jmlandmesser at gmx.de  Sat Dec 17 17:49:05 2022
From: jmlandmesser at gmx.de (John Landmesser)
Date: Sat, 17 Dec 2022 17:49:05 +0100
Subject: [Lazarus] LCL compilation fail for at least x86_linux
In-Reply-To: <202170dd-c9e5-7799-7845-ad90a60c6209@web.de>
References: <202170dd-c9e5-7799-7845-ad90a60c6209@web.de>
Message-ID: <68f5ed84-efdf-7df7-0313-db6374204628@gmx.de>

Am 17.12.22 um 17:14 schrieb Marcus Sackrow via lazarus:
>
> Hi,
>
>
> the LCL compilation fails since b40000c46c16207dc00997df6aeb83f01198787b
>
> for all platforms I let compile in my Jenkins for example x86_64-linux
>
>
> Compiling ./widgetset/wsforms.pp
> customform.inc(38,5) Warning: Case statement does not handle all possible cases
> customform.inc(647,3) Note: Local variable "NewState" not used
> customform.inc(1164,26) Error: Incompatible types: got "TAnchors" expected "Set Of TAnchorKind"
> customform.inc(1168,8) Error: Incompatible types: got "SYSTEM.UITYPES.TAnchorKind" expected "CONTROLS.TAnchorKind"
> customform.inc(1170,8) Error: Incompatible types: got "SYSTEM.UITYPES.TAnchorKind" expected "CONTROLS.TAnchorKind"
> forms.pp(2345) Fatal: There were 3 errors compiling module, stopping
> Fatal: Compilation aborted
> make[1]: *** [Makefile:4639: alllclunits.ppu] Error 1
> make[1]: Leaving directory '/var/lib/jenkins/workspace/LCL_off_x86_64-linux/lcl'
>
>
>
> full log at
>
> https://build.alb42.de:8081/job/LCL_off_x86_64-linux/12105/console
>
>
> Greetings,
>
> Marcus
>
>
>
No probs here on XFCE and Linux manjaro 6.0.11-1-MANJARO #1 SMP
PREEMPT_DYNAMIC Fri Dec 2 21:23:52 UTC 2022 x86_64 GNU/Linux

What i did:

Renamed existing folder lazarus, did a

git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git lazarus

and then in new lazarus folder

make clean
make all useride

Result:

Lazarus 2.3.0 (rev main-2_3-2521-gb40000c46c) FPC 3.2.2 x86_64-linux-gtk2

So lazarus just compiles fine ...

Regards

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20221217/e853ef73/attachment.htm>

From fpc at pascalprogramming.org  Sat Dec 17 18:25:58 2022
From: fpc at pascalprogramming.org (Marco van de Voort)
Date: Sat, 17 Dec 2022 18:25:58 +0100
Subject: [Lazarus] LCL compilation fail for at least x86_linux
In-Reply-To: <68f5ed84-efdf-7df7-0313-db6374204628@gmx.de>
References: <202170dd-c9e5-7799-7845-ad90a60c6209@web.de>
 <68f5ed84-efdf-7df7-0313-db6374204628@gmx.de>
Message-ID: <ab7460e0-e5a9-328d-d50b-09d087dfdcd9@pascalprogramming.org>


On 17-12-2022 17:49, John Landmesser via lazarus wrote:
>
> Lazarus 2.3.0 (rev main-2_3-2521-gb40000c46c) FPC 3.2.2 x86_64-linux-gtk2
>
> So lazarus just compiles fine ...
>
Copying a bunch of base types to uitypes has been committed to FPC 
trunk.? Marcus is probably using trunk.

Merging this to 3.2.4 is under debate. I favour merging it back to 
fixes, to keep the transition period as short as possible, since major 
releases are even slower to emerge than pointreleases.

From alb42 at web.de  Sat Dec 17 18:46:03 2022
From: alb42 at web.de (Marcus Sackrow)
Date: Sat, 17 Dec 2022 18:46:03 +0100
Subject: [Lazarus] LCL compilation fail for at least x86_linux
In-Reply-To: <ab7460e0-e5a9-328d-d50b-09d087dfdcd9@pascalprogramming.org>
References: <202170dd-c9e5-7799-7845-ad90a60c6209@web.de>
 <68f5ed84-efdf-7df7-0313-db6374204628@gmx.de>
 <ab7460e0-e5a9-328d-d50b-09d087dfdcd9@pascalprogramming.org>
Message-ID: <e010a78a-629b-cdd2-10b2-3c6bcc74ca53@web.de>

Hi,

Am 17.12.22 um 18:25 schrieb Marco van de Voort via lazarus:
>
> On 17-12-2022 17:49, John Landmesser via lazarus wrote:
>>
>> Lazarus 2.3.0 (rev main-2_3-2521-gb40000c46c) FPC 3.2.2
>> x86_64-linux-gtk2
>>
>> So lazarus just compiles fine ...
>>
> Copying a bunch of base types to uitypes has been committed to FPC
> trunk.? Marcus is probably using trunk.
>
> Merging this to 3.2.4 is under debate. I favour merging it back to
> fixes, to keep the transition period as short as possible, since major
> releases are even slower to emerge than pointreleases.

yes it is trunk, thats the second meaning of this jenkins compilation
because sometimes FPC fails only appear when compiling other sources
(like LCL)

and yes If I look more careful to, the compilatino was triggered by this
change in FPC

https://gitlab.com/freepascal.org/fpc/source/-/commit/d1616cb0d1210c44ab76807346e10dcba9ab6a63

Greetings,

Marcus


From lazarus at kluug.net  Sun Dec 18 08:52:33 2022
From: lazarus at kluug.net (Ondrej Pokorny)
Date: Sun, 18 Dec 2022 08:52:33 +0100
Subject: [Lazarus] LCL compilation fail for at least x86_linux
In-Reply-To: <e010a78a-629b-cdd2-10b2-3c6bcc74ca53@web.de>
References: <202170dd-c9e5-7799-7845-ad90a60c6209@web.de>
 <68f5ed84-efdf-7df7-0313-db6374204628@gmx.de>
 <ab7460e0-e5a9-328d-d50b-09d087dfdcd9@pascalprogramming.org>
 <e010a78a-629b-cdd2-10b2-3c6bcc74ca53@web.de>
Message-ID: <3da3c127-f79f-cfc2-e3f6-fa42af491670@kluug.net>

Am 17.12.2022 um 18:46 schrieb Marcus Sackrow via lazarus:
> Hi,
>
> Am 17.12.22 um 18:25 schrieb Marco van de Voort via lazarus:
>>
>> On 17-12-2022 17:49, John Landmesser via lazarus wrote:
>>>
>>> Lazarus 2.3.0 (rev main-2_3-2521-gb40000c46c) FPC 3.2.2
>>> x86_64-linux-gtk2
>>>
>>> So lazarus just compiles fine ...
>>>
>> Copying a bunch of base types to uitypes has been committed to FPC
>> trunk.? Marcus is probably using trunk.
>>
>> Merging this to 3.2.4 is under debate. I favour merging it back to
>> fixes, to keep the transition period as short as possible, since major
>> releases are even slower to emerge than pointreleases.
>
> yes it is trunk, thats the second meaning of this jenkins compilation
> because sometimes FPC fails only appear when compiling other sources
> (like LCL)
>
> and yes If I look more careful to, the compilatino was triggered by this
> change in FPC
>
> https://gitlab.com/freepascal.org/fpc/source/-/commit/d1616cb0d1210c44ab76807346e10dcba9ab6a63

Yes, sorry, I forgot to commit the Lazarus part of the patch yesterday.

It should be OK now.

Ondrej


From alb42 at web.de  Sun Dec 18 18:59:04 2022
From: alb42 at web.de (Marcus Sackrow)
Date: Sun, 18 Dec 2022 18:59:04 +0100
Subject: [Lazarus] LCL compilation fail for at least x86_linux
In-Reply-To: <3da3c127-f79f-cfc2-e3f6-fa42af491670@kluug.net>
References: <202170dd-c9e5-7799-7845-ad90a60c6209@web.de>
 <68f5ed84-efdf-7df7-0313-db6374204628@gmx.de>
 <ab7460e0-e5a9-328d-d50b-09d087dfdcd9@pascalprogramming.org>
 <e010a78a-629b-cdd2-10b2-3c6bcc74ca53@web.de>
 <3da3c127-f79f-cfc2-e3f6-fa42af491670@kluug.net>
Message-ID: <5bbf7e0d-bca2-5cf7-b472-1c613297ea5e@web.de>

Am 18.12.22 um 08:52 schrieb Ondrej Pokorny via lazarus:
> Am 17.12.2022 um 18:46 schrieb Marcus Sackrow via lazarus:
>> Hi,
>>
>> Am 17.12.22 um 18:25 schrieb Marco van de Voort via lazarus:
>>>
>>> On 17-12-2022 17:49, John Landmesser via lazarus wrote:
>>>>
>>>> Lazarus 2.3.0 (rev main-2_3-2521-gb40000c46c) FPC 3.2.2
>>>> x86_64-linux-gtk2
>>>>
>>>> So lazarus just compiles fine ...
>>>>
>>> Copying a bunch of base types to uitypes has been committed to FPC
>>> trunk.? Marcus is probably using trunk.
>>>
>
> Yes, sorry, I forgot to commit the Lazarus part of the patch yesterday.
>
> It should be OK now.

It all compiles fine now with trunk,

Thanks

Greetings,

Marcus


From lazarus2 at de-brouwerij.be  Mon Dec 26 15:41:08 2022
From: lazarus2 at de-brouwerij.be (Koenraad Lelong)
Date: Mon, 26 Dec 2022 15:41:08 +0100
Subject: [Lazarus] Application GUI does not appear
Message-ID: <1e27aa40-f135-4651-f58d-52d44bf9ce79@de-brouwerij.be>

Hi,
It's been a while since I did some development with Lazarus.
Now I wanted to update an application I wrote some years ago. At that 
time the application was written and compiled on and for Linux.
Now I want that application to run on Windows 11 64bit.
I installed the latest Lazarus (2.2.4 64bit) on a Windows 11 machine and 
copied my sources to that machine.
After some struggling with a missing library (libmysql.dll) I managed to 
run the original application. But I could not see the GUI.
Then I discovered I could not modify the forms, I simply can't see them. 
Pressing F12 does nothing but greying out the caption of the editor.
I can see the form of the datamodule though.
I used the "Check LFM-file in editor"-tool and that checks OK for the 
GUI-forms.
I added an msgDialog in the on-show routine of the main form and that 
does show. But when I click that away, nothing shows anymore, just the 
icon in the task-bar.

I created a minimal application and that does work fine.

Any Ideas what is happening ?

Thanks,
Koenraad

From michael at freepascal.org  Mon Dec 26 16:09:01 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Mon, 26 Dec 2022 16:09:01 +0100 (CET)
Subject: [Lazarus] Application GUI does not appear
In-Reply-To: <1e27aa40-f135-4651-f58d-52d44bf9ce79@de-brouwerij.be>
References: <1e27aa40-f135-4651-f58d-52d44bf9ce79@de-brouwerij.be>
Message-ID: <alpine.DEB.2.22.394.2212261604220.2637@home>



On Mon, 26 Dec 2022, Koenraad Lelong via lazarus wrote:

> Hi,
> It's been a while since I did some development with Lazarus.
> Now I wanted to update an application I wrote some years ago. At that time 
> the application was written and compiled on and for Linux.
> Now I want that application to run on Windows 11 64bit.
> I installed the latest Lazarus (2.2.4 64bit) on a Windows 11 machine and 
> copied my sources to that machine.
> After some struggling with a missing library (libmysql.dll) I managed to run 
> the original application. But I could not see the GUI.
> Then I discovered I could not modify the forms, I simply can't see them. 
> Pressing F12 does nothing but greying out the caption of the editor.
> I can see the form of the datamodule though.
> I used the "Check LFM-file in editor"-tool and that checks OK for the 
> GUI-forms.
> I added an msgDialog in the on-show routine of the main form and that does 
> show. But when I click that away, nothing shows anymore, just the icon in the 
> task-bar.
>
> I created a minimal application and that does work fine.
>
> Any Ideas what is happening ?

It could be that the support for High-DPI is messing with your forms. 
If the messagedialog works, it shows that the form is loaded and being shown.
Probably it has size zero.

So maybe check the form sizes in the lfm file, also check whether a
LCLVersion is being streamed. If so, maybe change its value to 2.2.4.0.

Michael.

From lazarus2 at de-brouwerij.be  Mon Dec 26 18:53:03 2022
From: lazarus2 at de-brouwerij.be (Koenraad Lelong)
Date: Mon, 26 Dec 2022 18:53:03 +0100
Subject: [Lazarus] Application GUI does not appear (solved)
In-Reply-To: <alpine.DEB.2.22.394.2212261604220.2637@home>
References: <1e27aa40-f135-4651-f58d-52d44bf9ce79@de-brouwerij.be>
 <alpine.DEB.2.22.394.2212261604220.2637@home>
Message-ID: <e76aa055-d9d7-0bac-4485-9750b4e8e735@de-brouwerij.be>

Op 26/12/2022 om 16:09 schreef Michael Van Canneyt:
> 
> 
> It could be that the support for High-DPI is messing with your forms. If 
> the messagedialog works, it shows that the form is loaded and being shown.
> Probably it has size zero.
> 
> So maybe check the form sizes in the lfm file, also check whether a
> LCLVersion is being streamed. If so, maybe change its value to 2.2.4.0.
> 
> Michael.

Hi Michael,

The application is intended to run on a small screen (i.e. 1280x1024). 
But I developed the application on a wide screen, so the forms were not 
visible on the small screen of the Windows PC. Your suggestion to look 
at the lfm solved the problem of not being able to edit/see the forms.
The problem when the application runs was similar. I store the place and 
size of the forms in an ini-file (iniPropStorage). And I copied that 
ini-file from my development machine to the windows machine.
Once I modified that ini-file I was able to see the GUI.

Thanks,

Koenraad.






From michael at freepascal.org  Sat Dec 31 19:07:56 2022
From: michael at freepascal.org (Michael Van Canneyt)
Date: Sat, 31 Dec 2022 19:07:56 +0100 (CET)
Subject: [Lazarus] Instantsearch package
Message-ID: <alpine.DEB.2.22.394.2212311900340.421859@home>


Hello,

As a late Christmas gift (and after some deliberation with Mattias Gaertner
who provided many helpful remarks), I've added a package to the lazarus IDE: 
InstantSearch.

It provides as-you-type search possibilities, which is much faster than the
current find-in-files.

For it to work, it needs to index sources. The sources are organized in
source trees, and you can define as much "source trees" as you wish. 
The RTL, FCL, compiler and LCL are added by default.

Projects can be marked as 'indexable' and the current project can be 
indexed & searched as well.

Conceivably, other sources of info can be indexed: WIKI, Help, etc...

It currently uses "Manticore Search" as a backend (because it has a simple
install and interface), but other engines can be added if so desired.

More help can be found here:
https://wiki.freepascal.org/Lazarus_InstantSearch

Should you experience problems, don't hesitate to reach out.

Enjoy !

Michael.