[fpc-devel] Delphi-like Packages, Plan

[Marco van de Voort]

In our previous episode, Dimitri Smits said:
> > 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).
> 
> only the symbols that are used are imported in the dyn-loaded package. And
> it exports all publicly available types/procs/consts/vars.

No, also the amounts needed from e.g. LCL to FCL and RTL packages. And those
have high granularity (and the program->LCL might also be quite high)
 
> > The KDE suites startup speed problems have shown that very
> > complicated
> > dynloading schemes are not desirable.
> > 
> > The RTL is always loaded on startup btw.
> 
> to say even more, when you run with runtime packages, it's units are
> initialized first (before any other units/bpl's/the main exe).

I think this discussion should first define some terms wrt "building with
packages" vs "safeloadpackage".  Dynamic is a too vague term.

I was mostly thinking Hans-Peter meant doing loadpackage() under the hood. I
think that is, if viable at all, an extreme specialty which shouldn't be
considered at all in the first run.

In later mails I got the impression he didn't mean that, but normal
static-dynamic linking. (importlib static, code dynamic in dll/bpl)
 
> > Problem is that that leads to a dependancy circle (pkg->exe->pkg).
> > Maybe not
> > a blocker problem, but more a complication.
> > 
> 
> when you use packages, it requires some discipline, that is right.
> Consider following scenario:
> 
> pkg1: your plugin-base classes, requires RTL package exe: imports pkg1 as
> a runtime package requirement, statically binds the gui components in
> lcl/vcl since it was not defined as a runtime package link requirement

> pkg2: a plugin for runtime loading, requires RTL package and VCL/LCL
> package

> what would be result when you want to import this at runtime through a loadlibrary call?

((safe)loadpackage?)
 
> I would suspect that you then have "duplicate units"-error. Compiler
> cannot defend against it due to the "runtime" information vs
> "compile-time" information.

Correct. Since LCL might hold state, it violates the rule that the whole of
the packages system may hold only one instance of a certain unit state (its
variables, but also VMT tables, see wiki)

> Just to show that packages bring their own set of problems and pitfalls. But definately not all is bad ;-)

This is all known, and described in the wiki afaik.
 
> > 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.
> 
> that is why versionnrs are included: RTL70.BPL (Delphi 7) vs RTL150.BPL (Delphi XE aka 2011)

That's the first order defence yes, to allow multiple installs. But the
packages system should be safeguarded against any kind of tampering, based
on CRCs or other .ppu version items.  Since with the openess and snapshot
generation of FPC/Lazarus, even two builds from different periods with the
same number will usually be incompatible.

(CRCs of the interface of the relevant ppus I think, as currently is done
with ppu's too)