* * *

Author Topic: PPL = fpc's BPL ?  (Read 658 times)

x2nie

  • Sr. Member
  • ****
  • Posts: 464
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
PPL = fpc's BPL ?
« on: May 16, 2018, 08:27:44 am »
Hi all ! :)


I am finding a way to bring my project LiteZarus (Lazarus too of course, if possible) to be more closely to Delphi7,
in the way like of fast compiling designtime package.


I mean, there shall an easy way to load/unload Lazarus packages (design time package too) IMHO,
just as similar as Delphi ability to quickly install/upgrade/uninstall *.BPL packages.
I think it worth to have this feature, especially for package developer.
Because "Time is competitive weapon" --Andrew S Grove.


So, I start learning ppdump and ppmove.
Luckily I found that FPC already has a tool to generate a PPL file which is less-more like the BPL.
here ftp://www.stud.tue.nl/mirrors/.www/fpc/tools/ppumove.html
Quote
ppumove collects one or several Free Pascal unit files and archives them in a static or shared library.


Also here: http://wiki.freepascal.org/Lazarus/FPC_Libraries#ppumove.2C_.ppu.2C_.ppl
Quote
The ppumove tool included with every FPC installation, converts one or several .ppu and .o files into a dynamic library. It does this by calling the linker to gather all .o files into a .so (windows: .dll) file and removes the .o filename references from the .ppu file. These new .ppu files are normally called .ppl files.


So finally we already have had BPL (PPL) for freepascal+Lazarus, didn't we?
-------------------------


Well, now, by the assumption of PPL = BPL = dynamic library  , Lazarus can easily load/unload/recompile a package without recompile the lazarus.exe. That is my big dream.

My Questions now:
1. Is there any sample / demo of PPL usage? I didn't found any
2. Can we load/unload PPL in runtime ? I assumed PPL is "dynamic library"


I am crazily happy reading below article, but do not sure if it still relevant:
Quote
For example:
You have the output directory of a package (where the .ppu files are):
ppumove -o packagename -e ppl *.ppu
This will convert all .ppu files into .ppl files and creates a libpackagename.so (windows: packagename.dll). Note that under Linux the prefix 'lib' is always prepended.This new library can already be used by other programming languages like C. Or by FPC programs by using the external modifiers. But the initialization/finalization sections must be called automatically. This includes the initialization/finalization of the heap manager. This means no strings or GetMem. Of course FPC programmers are spoiled and they can get more.
(in second link above)


It's maybe a long road to walk by, or almost impossible, but I think it is not impossible. 8-)
« Last Edit: May 16, 2018, 09:09:05 am by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Leledumbo

  • Hero Member
  • *****
  • Posts: 7869
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: PPL = fpc's BPL ?
« Reply #1 on: May 16, 2018, 06:49:00 pm »
Your post remind me of the dynamic packages plan. AFAIR last time it was demonstrated to be working, but no idea what's next. PPUMove seems to be working, though. It didn't last time. I tested it on brook framework and I get a single .so containing all symbols in the corresponding .o. I just don't know how to link this .so with my app through the .ppl.

x2nie

  • Sr. Member
  • ****
  • Posts: 464
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: PPL = fpc's BPL ?
« Reply #2 on: May 16, 2018, 09:07:03 pm »
Your post remind me of the dynamic packages plan. AFAIR last time it was demonstrated to be working,
How? when? where? Is there any URL to learn/try with?
Any info (even at few/tiny amount)  about dynamic package would be very valuable for me 8-)


Quote
PPUMove seems to be working, though. I tested it on brook framework and I get a single .so containing all symbols in the corresponding .o.
Unfortunatelly it didn't work in my side (WinXP + FPC 3.0.0)
following previous command in console, the generated ppl is not a collection of PPU, instead the are generated as much as amount of PPU count. Let say from 10 ppu ~-> generated 10 ppl.
Perhaps ppumove is for linux only? >:D  There is no such .dll created in windows.
Well, ppumove could generate a sinble pmove.bat batch-file, but didn't work either :'(  (raised unknown error)
Quote
I just don't know how to link this .so with my app through the .ppl.
I guessed that the *.so is just common dynamic lib, so that might need some "export" things


Anyway, when I were a student, there are TPUMove (turbo-pascal-compiled/binary-unit-management) that can be used to remove/append a tpu into package. Perhaps it has similar purpose.?
« Last Edit: May 16, 2018, 09:12:31 pm by x2nie »
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

Leledumbo

  • Hero Member
  • *****
  • Posts: 7869
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: PPL = fpc's BPL ?
« Reply #3 on: May 17, 2018, 12:40:25 am »
How? when? where? Is there any URL to learn/try with?
Any info (even at few/tiny amount)  about dynamic package would be very valuable for me 8-)
If I'm not mistaken it was presented by Almindor and Sven in a Pascal event.
Unfortunatelly it didn't work in my side (WinXP + FPC 3.0.0)
following previous command in console, the generated ppl is not a collection of PPU, instead the are generated as much as amount of PPU count. Let say from 10 ppu ~-> generated 10 ppl.
That's how it's designed to work (see its documention below). So the idea is to distribute all the .ppl and the single .so, as opposed to all .ppu and .o. It could be that the compiler will be made possible to see .ppl as alternative to .ppu and it knows the connection to .so. So, for each unit in uses clause, if the compiler sees .ppl, that unit will be linked dynamically. Otherwise if it sees .ppu, it will be linked statically. It's just... not implemented yet.
Perhaps ppumove is for linux only? >:D  There is no such .dll created in windows.
Well, ppumove could generate a sinble pmove.bat batch-file, but didn't work either :'(  (raised unknown error)
No, it was simply an unfinished product. It should work on all platforms eventually.
I guessed that the *.so is just common dynamic lib, so that might need some "export" things
Not that simple. We have syntax for importing procedural stuffs, this .so contains class structures and their methods, which we don't have syntax support for. How does Delphi import .bpl things containing classes?
Anyway, when I were a student, there are TPUMove (turbo-pascal-compiled/binary-unit-management) that can be used to remove/append a tpu into package. Perhaps it has similar purpose.?
Yes, per its documentation.

PascalDragon

  • Full Member
  • ***
  • Posts: 101
  • Compiler Developer
Re: PPL = fpc's BPL ?
« Reply #4 on: May 19, 2018, 09:36:40 am »
First of, yes, PPL is FPC's equivalent of Delphi's BPL.

However I'd definitely not advice to use ppumove as that as some serious restrictions:
  • works only on targets that don't need indirect imports (e.g. Windows is out with that)
  • does not support dynamic loading
  • does not check whether the packages are still acceptable after a recompile

This is where true support for dynamic packages comes in which is still a WIP though definitely further than a few years ago. The groundwork of changing some references to indirect ones (e.g. RTTI and VMT data) to support the indirect imports required on Windows platforms is already done and the startup code of i386-win32, x86_64-win64, x86_64-linux and all Mac OS X targets is already converted to support dynamic packages.
Having the compiler compile an application that uses packages at compile time is already possible (if dynamic packages are enabled for that target and package files are available as well (e.g. "rtl", "rtl.objpas", "fcl.base", etc.)).
The big chunk missing is dynamically loading a package which requires some changes to the way units are managed inside an application to address the issue of units and their types to be dynamically added and removed during the application's lifetime.

x2nie

  • Sr. Member
  • ****
  • Posts: 464
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: PPL = fpc's BPL ?
« Reply #5 on: May 20, 2018, 05:00:57 am »
The big chunk missing is dynamically loading a package which requires some changes to the way units are managed inside an application to address the issue of units and their types to be dynamically added and removed during the application's lifetime.
I didn't really undestand what it is mean of? Your last paragraph is a bit complicated words for me.
By the way, I smell that is a challenge to Lazarus IDE to recognize any invalid package because of mismatch version of unit in contained in  that package.
Am I right?
When you were logged in, you can see attachments.
Lazarus Trunk @ Windows7 64bit, XP 32bit, Debian under VirtualMachine

PascalDragon

  • Full Member
  • ***
  • Posts: 101
  • Compiler Developer
Re: PPL = fpc's BPL ?
« Reply #6 on: May 20, 2018, 03:03:20 pm »
When a dynamic package is loaded using LoadPackages() or unloaded with UnloadPackage() there are various house keeping tasks that the RTL needs to do:
- initialize or uninitialize units as needed
- insert new types into the public type list for correct support in the Rtti unit
- insert new resource strings into the internal resource string list for correct support (plus notification for translation handling units so that they know that something new needs to be translated)
- some other things that I don't have in my sight right now

Additionally the compiler needs to generate meta data for each package so that the RTL can ensure that a loaded package (and its dependencies) is compatible with the running application.

Lazarus itself won't have to deal with that. It simply needs to handle LoadPackage raising an exception if a package is not compatible as the main work is done by the RTL.

 

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus