Windows Installer with FPC-including-debug-info

[Martin_fr]

I made a few changes to the Windows installer.

I added the possibility of providing a 2nd FPC that has debug info included.

This requires Lazarus 4.99. So the test-downloads are build on the git main branch.
The test builds all are build with the FPC 3.2.4-rc branch.

The build contain the normal setup files.
- those now allow to install into a folder with spaces, but this is not tested, and at your risk.

And there is a file fpc-3.2.4-rc1-30dd873d32-win64-for-lazarus.exe (win32 for 32 bit). The filename should contain "debug", but I forgot. This contains the debug fpc. This file is to be installed as add-on, into the same folder as lazarus is installed to.
The file install an fpc in your-lazarus-dir/fpc-dbg/*

Once this is installed you can change between the 2 compilers by changing the path between fpc and fpc-dbg.

This may not be the most convenient, but there is currently no way for 1 single fpc to produce both kind of executables.

If you are testing this you may also want to look at "excluded routines" in the debugger settings (global and/or project). This allows you to prevent stepping into routines you aren't interested in (e.g. maybe object checks before calling a virtual method).


The test installers are here:
32bit: https://sourceforge.net/projects/lazarus-snapshots/files/Window%2032/2026-07%20lazarus-4.99-fcc2360a44-fpc-3.2.4-rc1-30dd873d32/
64bit: https://sourceforge.net/projects/lazarus-snapshots/files/Window%2064/2026-07%20lazarus-4.99-fcc2360a44-fpc-3.2.4-rc1-30dd873d32/

[ALLIGATOR]

I think this is great news. For those power debugging users who use stable releases instead of sticking with git[main].

But what about switching the path to the compiler... doesn’t it seem like there’s a slightly easier way to do it?

After all (as far as I understand), it’s all about fpc.cfg and the path to the units folder, right?
And the compiler can parse environment variables in fpc.cfg.

So, if you change this (fpc.cfg):

Code: [Select]

...
-FuC:\lazarus\fpc\$FPCVERSION/units/$fpctarget/$fpcsubarch-$fpcmemorymodel/rtl
...
To this (fpc.cfg) (changed this: units-$fpcbuildmode):

Code: [Select]

...
-FuC:\lazarus\fpc\$FPCVERSION/units-$fpcbuildmode/$fpctarget/$fpcsubarch-$fpcmemorymodel/rtl
...
Then maybe we could just distribute an installer that simply adds an extra units folder

And Lazarus will set the environment variable (fpcbuildmode) itself before running the compiler

[Martin_fr]

At some point FPC will get sub-targets (e.g. for widechar rtl). Then those can be used. And I am sure those will be added to Lazarus too.

The compiler btw can be set in the  Project options. Not sure if IDE macros can be used there.

You can try and just modify the fpc.cfg  that you already have. Because ultimately you have that 2nd set of units. You just would have to put the env var earlier in the path
-FuC:\lazarus\fpc$FPCXTRA\$FPCVERSION/units/$fpctarget/rtl

and FPCXTRA could be empty or -deb

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

I havent checked what args need to be given to fpcmkcfg to generate such a cfg file as you describe.

And, it then leaves the question
- modify the core installer so this is prepared already? But then if users set that env var by accident / for other reasons without knowing
- modify the conf when installing the add-on => but that needs a switch so users can choose (and if it goes wrong the installer breaks the existing install)
- adding this to the new install => so you can switch compiler once, and then do the env

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

But there is more. I had to go out of my way to ensure the IDE recompiles packages after the switch.

I am not sure why => the RTL ppu should be compatible? (checksums should not depend on opimization?) Or maybe they do when there are inlines?

In anyway, if the IDE does not recompile its packages, the you get an error that the checksums don't match.

And for the IDE to do that the compiler must change.

That is why it can't be done with current 4.8 => because it wouldn't detect this. 4.99 has a different way to check that.