[fpc-devel] Packages, Generics

[Dimitri Smits]

appareantly this one didn't get through

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

> Am 13.09.2010 14:46, schrieb Dimitri Smits:
> > 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.
> 
> Basically the package system needs the following:
> 
> - The ability to import/export functions, procedures AND variables
> from 
> binaries (although export from shared library only should be 
> sufficient). This works on Windows, but on Linux I had problems.
> - The ability to declare init and finit procedures for shared images.
> 
> This works on Windows with the entry point and on Linux with special 
> symbols. I don't know about the other platforms.
> - The ability to add the init/finit entries (which call the unit 
> initialization/finalization sections) uniquely to the shared RTL and 
> execute them. This is of yet a todo as it means a bit of work in the
> RTL.
> 
> The first two points must be provided by the platform/OS while the
> third 
> one is defined by us (at best as the same for all platforms).
> 
> 
> What would you do different/better then the Delphi developers when 
> implementing such a package system in a crossplatform way?
> I can't imagine currently what should be done additonally, but that 
> might be because I don't use every feature that FPC provides. So
> please 
> share your ideas. :)

a few "cleanups" and "improvements" I'd sneak in are due to the fact that Delphi comes as a whole: VCL and compiler are distributed. Building for a version is building that version.

FPC and it's close companion Lazarus are not like that. Compiler is released a few times a year (?), IDE and visual componentset are separate. There is not really a maximum requirement for what compiler you use to build the IDE and components. There is sometimes a minimum version requirement.

DLL-hell is bigger, I know. However, take for instance LCL 1.0. (LCL-win32-1.0_fpc2.4.fpl ?) The requires could take just LCL-win32-1.0 as package name and "rtl". 

Another thing I'd place inside the packageinfo is the compiler with which the package was build (for runtime checking). I do not believe that a version like 2.4.2 should contain other EABI/RTTI or even as worse: other interfaces. They are bugfixes (?).

So 2.4.0 can work with 2.4.2 packages.

Also, some packageinfo+unittableentry stuff is less than optimal in alignment with the shortstrings iso pchar? Something I've found bizarre with Delphi 7 RTTI in typeinfo as well. 

Every unit has a local "tunitinfo" block generated:

tunitinfo=record
  ...
  unitname: shortstring;
end;

punitinfo=^tunitinfo;

tunittableentry=record
  init, finit: pointer;
  unitinfo: Punitinfo;
  typecount: cardinal;
  unittypes: pptypeinfo; // array[0..typecount-1] of ptypeinfo for all the types in interface & implementation
end;

Every package/exe(!)/library(!) has a packageinfo table with all the contained (implicitly/explicitly) units in order (like now) of dependencies containing a link like punittableentry. Yes, the executable is a package too!

Another thing is what to do with weak packages or what with "if you include this unit first in your project, then it will be initialized after system... for instance a memorymanager-swap"? Packages and the used/described register-init order implies that when you use a memory manager like that, a lot of memory can have been allocated during "init" of units using the default manager before a swap happens.

one can mediate that a bit if one can indicate the order of "build with runtimepackages" and if "rtl" contains no units that allocate memory (direct/indirect) in their init sections.

So, working further on the "register packages first, then initialize in order" doctrine, one can make the above records and especially the unittableentries and/or table as a doubly linked list. But that is just an idea.

I'm gonna stop here, because packages entail ofcourse a lot more than RTTI or dll generation/ini/fini. This is just the top of the iceberg.

kind regards
Dimitri Smits