[fpc-devel] Delphi-like Packages, Plan

Marco van de Voort marcov at stack.nl
Mon Oct 4 10:39:35 CEST 2010


In our previous episode, Willibald Krenn said:
> > I don't like the Delph all-or-nothing philosophy here. I'd prefer to
> > specify the packages, that shall be loaded at runtime, while all other
> 
> You can always load packages at runtime.. That is, after the RTL 
> supports that of course.

Runtime loading of loading is quite a different process from startup
loading, and only used for plugin system (where the baseclass is statically
linked, and the plugins implement the baseclasses). Dynamic loading for
enormous amounts of symbols might be costly (since they are resolved with a
call per symbol, instead of by one call to the system, as during startup).

The KDE suites startup speed problems have shown that very complicated
dynloading schemes are not desirable.

The RTL is always loaded on startup btw.
 
> > packages can be linked into the executable. This would allow to use an
> > minimal set of external modules, which are shared by the exe and the
> > really self-contained packages.
> 
> What you probably(?) could do is to link all basic packages into the 
> executable but still export all symbols, so that when the shared object 
> is loaded it finds all necessary entry points.

Problem is that that leads to a dependancy circle (pkg->exe->pkg). Maybe not
a blocker problem, but more a complication.

> However, at the moment I don't see why this is better than shipping all 
> necessary ppl files. BTW: I realize that ppl might be a bad TLA - since 
> it probably means "people" for quite a number of ppl ;-)

Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible
too eachother anyway.
 



More information about the fpc-devel mailing list