[fpc-devel] Packages, Generics

[Dimitri Smits]

----- "Sven Barth" <pascaldragon at googlemail.com> schreef:

> Am 13.09.2010 11:44, schrieb Willibald Krenn:
> > But enough about generics, back to packages: I'll start doing an
> implementation for the non-generic part first. Let's see how this
> goes. Since I need to read into fpc source (and do this in my spare
> time), don't expect any spectacular results soon. In case there are
> more people interested in implementing this, some branch in the repo
> would be needed - if I am the only one, I will do this locally on my
> disk.
> 
> You might want to start compiler/pmodules.pp. There is already some
> code 
> to parse "package" projects and some code that allows all symbols to
> be 
> exported (this code also appears in ppumove, but only for Linux and
> DOS).
> 
> I've stumpled upon this code last week and tested it on a Linux
> system. 
> Compiling a simple package with a single unit works if I use Win32 as
> 
> target. A .dll (wrong file extension) is generated which exports all 
> functions/procedures that are in the interface of my unit or the RTL 
> units, but no variables are exported although the Win32 target
> supports 
> this (tested before the package). Using Linux as a target results in
> an 
> internal error and I've not yet found the time to investigate this.
> 
> Also "requires" sections aren't parsed yet.

how about "contains" sections?

> In theory(!) it should be "rather" simple to implement shared cross 
> platform packages (those that are loaded on app startup by the OS and
> 
> not dynamically during the run).
> 

that would require a change in sysinit, sysutils & system units as well, all types of linked-target modules (executable, shared lib, package) should "register" their moduleinfo ('hinstance' of the module, list of contained units' table entries => init, finit pointers) in startupcode for the module. shutdown code for the module should deregister that moduleinfo.

for somewhat of a breakdown, look at TLibModule, LoadPackage, UnloadPackage and related functions for inspiration:

http://docwiki.embarcadero.com/VCL/en/System.TLibModule
http://docwiki.embarcadero.com/VCL/en/System.LibModuleList
http://docwiki.embarcadero.com/VCL/en/System.RegisterModule
http://docwiki.embarcadero.com/VCL/en/System.UnregisterModule
http://docwiki.embarcadero.com/VCL/en/SysUtils.LoadPackage
http://docwiki.embarcadero.com/VCL/en/SysUtils.UnloadPackage

and related
http://docwiki.embarcadero.com/VCL/XE/en/System.TModuleUnloadProc
http://docwiki.embarcadero.com/VCL/XE/en/System.AddModuleUnloadProc
http://docwiki.embarcadero.com/VCL/en/System.RemoveModuleUnloadProc
http://docwiki.embarcadero.com/VCL/en/System.EnumModules
http://docwiki.embarcadero.com/VCL/en/System.EnumResourceModules
http://docwiki.embarcadero.com/VCL/en/SysUtils.InitializePackage
http://docwiki.embarcadero.com/VCL/en/System.PackageInfoTable
http://docwiki.embarcadero.com/VCL/en/System.UnitEntryTable
http://docwiki.embarcadero.com/VCL/en/System.PackageUnitEntry


sysinit, system, sysutils:
the initialization of an executable/package/library needs to be completed with filling in the libmodule structure (needs to be generated as well) with the moduleid (portably!) and the pointer needs to be given to registermodule. In delphi a check occurs somewhere on all the "included" units of a package/dll/exe to see if there is a duplicate unit loaded.

loadpackage does nothing more than dlopen() of a file, and then the resulting recently added libmodules that were added are then initialized by init-ing their unittable entries.

conversely, unloadpackage finit's all those units and dlclose().

finalization of an executable/package/library unhooks the libmodule

addmoduleunloadproc/removemoduleunloadproc are invoked either by unloadpackage or by unregistermodule.

---

as said before, inspiration can be had from how they do it, but that doesn't mean fpc should do it that way. Especially in a crossplatform context, and more so cross-architecture, it is not a one-size fits all per se.


kind regards,
Dimitri Smits