[fpc-devel] FPC dynamic libraries

[Michael Van Canneyt]

On Thu, 8 Feb 2007, Daniël Mantione wrote:

> 
> 
> Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
> 
> > > Design a plugin binary API, dynload the plugin. It is not necessary that 
> > > the RTL is shared for this purpose (allthough it could reduce the size).
> > > 
> > > This way you only have to keep the plugin API backwards compatible, 
> > > and could allow binary plugins to be used with any Lazarus version. 
> > > Keeping a plugin API compatible is very doable, unlike of the full RTL, FCL 
> > > and LCL, which seems next to impossible to me.
> > 
> > Why ?
> 
> There is OOP code in those libraries. The slightest code modification will 
> change the layout of the VMT.

Yes.

> 
> > Borland does it.
> 
> Borland does not. Each Delphi version has its own BPL packages, for 
> example you have vcl50.bpl. The only reason it is workable with Delphi is 
> that they don't release very often.

Exactly. 
Neither does FPC. Not an offical release, anyway. 
We don't release that much more often as Borland.

> > Secondly, there are serious problems with this approach which make it unusable
> > for an IDE like Lazarus.
> > 
> > Assume I get a component instance from the plugin (MyObject), then extremely 
> > simple and basic statements like
> > 
> > If (MyObject is TComponent) then
> >   XYZ
> > 
> > will fail, even though MyObject is a TComponent, because the VMT of the 
> > MyObject TComponent parent resides in the library, and the VMT of TComponent
> > used in the If statement is inside Lazarus, causing the statement to fail, 
> > even though it should be true. When using packages, the statement will function
> > correctly.
> 
> I was talking a binary API, and that automatically disallows sending 
> classes through the API, because you want to prevent that an internal 
> change breaks your external API. Simply design the API in a proper way.

You can't, for Lazarus. You need the classes, that's what you need the
plugins for in the first place: to install additional components on the 
component palette. They must descend from the TComponent which is in
the IDE.

There is no way around it.

> > The only option are packages, and packages need an RTL in a dynlib.
> > That this requires a strict versioning schedule, is part of the deal. 
> 
> Indeed, and because this is not a workable solution, just count the 
> number of changes in the VCL, a proper designed binary API is what you 
> need.

I understand that, but this is not usable at all for an IDE based on class 
components.

> 
> > Borland's packages are also incompatible between released versions.
> 
> Sure, but above you said Borland keeps them compatible.

With this I mean that they release not so often that it becomes a problem.
if they would release every 3 weeks, it's a problem, this is obvious.

Lazarus will have to do the same if they want to have dynamically loadable
packages. 

Michael.