Recompile FPC Package

[Weitentaaal]

Hello,

i wanted to reinstall the Package "fcl-pdf" because it hase some Fixes that i need. How do i recompile the package ?i found some posts about this already but i thought i would ask and maybe find an easier way to do it (i don't want to break my installation). i did download it from here: "https://gitlab.com/freepascal.org/fpc/source/-/tree/main/packages/fcl-pdf" and then replaced the package in my install folder. Now i need to recompile it. How should i do that ?

[marcov]

Easiest: recompile everything in order (fpc - lazarus - additional packages).

If you feel like taking a chance, you could erase (or move away) the fcl-pdf directory in the fpc\units\<target>  directory and replace it with the compiled files of the newer ones.

That only works if nothing else precompiled depends on it. If only lazarus packages depend on it, let lazarus rebuild itself.

[Weitentaaal]

do i need trunk to recompile everything ?

or can i use the script from this site: "https://wiki.lazarus.freepascal.org/FPC_recompilation_automation" also with a normal installation ?

[Khrys]

(Assuming 64-bit Windows and FPC 3.2.0; paths may need to be adjusted)

Replace  C:/lazarus/fpc/3.2.0/source/packages/fcl-pdf  with the new version of the package's source and run the following in a command line, in that directory:

Code: Text  [Select][+][-]

1. fpc fpmake.pp && ./fpmake --globalunitdir=../../..

Now you can copy the contents of the newly created  units  build directory into C:/lazarus/fpc/3.2.0/units/x86_64-win64/fcl-pdf.

But like Marco said, replacing a single package with another version is quite unlikely to work - so I wouldn't really recommend this approach.

[TRon]

do i need trunk to recompile everything ?

No in case you are currently not using trunk compiler and yes if you currently use trunk compiler (see below)

In case using something like 3.2.2 (not trunk compiler) and if you are lucky then you should be able to get the trunk fcl-pdf sourcecode and compile that with your existing compiler.

It can get more complicated if other packages depend on (individual) units of the fcl-pdf package. In that case you need to recompile those as well.

or can i use the script from this site: "https://wiki.lazarus.freepascal.org/FPC_recompilation_automation" also with a normal installation ?

Assuming that you are currently using FPC 3.2.2 then no. In case you want to update a trunk (currently 3.3.1) compiler then just do a checkout and a complete recompile (the script is then applicable) as it leaves no room for errors.

[Weitentaaal]

i am not using trunk so i would just need to recompile the package with that command.

in the case that it doesn't work. How would i recompile whole fcl ?. would it be possible to just delete all compiled packages in "\fpc\units\x86_64-win64\" and then recompile them in "..\fpcsrc\packages\" using the command provided by @Khrys and move the recompiled packages back to "\fpc\units\x86_64-win64\".

The newer package version added some support for the pdf units.

[TRon]

i am not using trunk so i would just need to recompile the package with that command.

In that case then you could try to get away with compiling the fcl-pdf package by downloading the source-code for that package using your current compiler.

That does not have to be difficult. You should be able to do that with compiling each individual unit. As said before if other packages depends on one of the units from the fpc-pdf package then these need to be recompiled as well.

in the case that it doesn't work. How would i recompile whole fcl ?. would it be possible to just delete all compiled packages in "\fpc\units\x86_64-win64\" and then recompile them in "..\fpcsrc\packages\" using the command provided by @Khrys and move the recompiled packages back to "\fpc\units\x86_64-win64\".

I cannot comment on the command presented by Khrys simply because I've never done that myself this way. In basics you can remove the existing package(s), recompile them and replace. As also indicated you woul d then need to recompile Lazarus as well (but that is a one button action)

The newer package version added some support for the pdf units.

Yes, I understand. Do realize that it might be that the changes/fixes in trunk rely on new FPC features not present in your  current installed FPC (if not mistaken then you still forgot to mention your version number of FPC which is important).

I am not behind a development machine so can't check for you right now (but can do so later today).

[marcov]

in the case that it doesn't work. How would i recompile whole fcl ?. would it be possible to just delete all compiled packages in "\fpc\units\x86_64-win64\" and then recompile them in "..\fpcsrc\packages\" using the command provided by @Khrys and move the recompiled packages back to "\fpc\units\x86_64-win64\".

Partial compiles are much more dangerous then just cleaning/backing up the old, and recompiling everything. So while possible in theory, this is expert territory that knows all dependencies by heart.

[wp]

Regarding your original issue with the fcl-pdf package, I would try to copy its units into a separate folder of your project and set the path to "Other unit files" to this directory, In this case, your FPC would use these units for your application and ignore those from the FPC installation folder. Of course, this works only when there are no other packages which FPC or Lazarus knows to depend on fcl-pdf. But it's worth a try. If it does not work, just delete the fcl-pdf folder from your project and delete the compiled units folder (usually:lib) so that FPC will use the old units again.

[Soner]

Use Console/Terminal/cmd:
1. Only on windows, when fpc is "unknown":
set PATH=%path%;c:\lazarus\fpc\3.2.2\bin\i386-win32
2. Change to fcl-pdf folder C:\lazarus\fpc\3.2.2\source\packages\fcl-pdf
3. Then call make
4. Now you have in subfolder units the new compiled-units, copy them to c:\lazarus\fpc\3.2.2\units\i386-win32\fcl-pdf

Thats all. I didn't test this now, but I did it this way with fcl-db.

The folders may be named differently depending the system you are using.

[TRon]

I am not behind a development machine so can't check for you right now (but can do so later today).

Unfortunately updating the fcl-pdf package sources of FPC 3.2.2 with trunk, then re-compiling (cross for me) all the packages failed for me with

Code: [Select]

Free Pascal Compiler version 3.2.2 [2021/05/16] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling fcl-pdf/src/fppdf.pp
fppdf.pp(1250,85) Error: Incompatible types: got "Empty Set" expected "TDashArray"
fppdf.pp(1341,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
which seem to indicate that something else has also changed (in trunk) that the fcl-pdf package depends on...

Is there any reason @Weitentaaal for not installing trunk compiler alongside your existing installation ?

[Weitentaaal]

Is there any reason @Weitentaaal for not installing trunk compiler alongside your existing installation ?

yes i work with other people on this Project and they do not want to update Lazarus/FPC yet. So i cant work with them when they have an older version of Lazarus, because they can't open/compile my work.

i guess the best way for me now is to leave it for now since i can't just recompile the single package due to dependencies. I will mark this section in the project as unfinished and come back later when all of my coworkers agree to update Lazarus.

i do not have any knowledge about fpc so thats one more reason to stop here and come back later when i have a clean and safe Updated version. Maybe this thread could help someone else in a similar situation.

Thank all of u guys for stopping by and helping me.

[Khrys]

If all you need are some bugfixes, then maybe it's possible to write a non-invasive "patch" using Pascal's identifier scoping rules and type helpers. Here's an example of what I mean by that:

In the LCL version I'm using, TFont.Assign doesn't copy the  PixelsPerInch  property - which is a problem for me. So I wrote the following type helper:

Code: Pascal  [Select][+][-]

1. {$modeswitch typehelpers}
2.  
3. implementation
4.  
5. type
6.   TFontHelper = class helper for TFont
7.   public
8.     procedure Assign(Source: TFont); // reintroduce; (if it were a subclass)
9.   end;
10.  
11. interface
12.  
13. procedure TFontHelper.Assign(Source: TFont);
14. begin
15.   PixelsPerInch := Source.PixelsPerInch;
16.   inherited Assign(Source);
17. end;

Now whenever this type helper is in scope, any call to  Assign  resolves to the patched version - without having to change each occurrence manually.
A limitation of this approach however is that type helpers can't introduce new data fields, so depending on the complexity of the required fixes it may not be applicable.

[paweld]

@Weitentaaal: You can do as @wp wrote - put the modified version "fppdf.pp" in the project source directory (or a subdirectory and specify this path in the "Other unit files" parameter in the project properties)

[TRon]

@Weitentaaal: You can do as @wp wrote - put the modified version "fppdf.pp" in the project source directory (or a subdirectory and specify this path in the "Other unit files" parameter in the project properties)

No because the sources from trunk for package fcl-pdf rely on new functionality provided by the trunk compiler. FPC 3.2.2 is not able to compile the trunk package.