[fpc-devel] Dnamic packages support

[Michael Van Canneyt]

On Sat, 3 Nov 2007, Florian Klaempfl wrote:

> Michael Van Canneyt schrieb:
> > 
> > On Sat, 3 Nov 2007, Florian Klaempfl wrote:
> > 
> >> Leonardo M. Ramé schrieb:
> >>> Reading a post in "public.mseide-msegui.talk", the mseide discussion
> >>>  list, I found this:
> >>>
> >>> "Florian has committed the beginning of dynamic packages support".
> >>>
> >>> With "Dynamic Packages" you mean a platform independent way of
> >>>  implementing something similar to
> >>> .Dlls (or .bpl)? without creating each library its own memory manager?,
> >>>  where objects can flow
> >>> across all libraries without problems?
> >>>
> >> If it is finished, it would be something like this yes. However, I'am
> >> not convinced of the use of dyn. loaded packages for an OSS project so I
> >> played only with it.
> > 
> > Hm. I don't see what OSS or not OSS has to do with it ?
> 
> Packages have major drawbacks
> - DLL/shared lib hell; remember each fpc build gets/needs it's own set
> of packages

I don't see this as a problem. We release only once a year.

> - memory footprint of programs increase significantly since no
> smartlinking is possible, I created once a pure shared linked lazarus:
> it depended on 50 MB of shared libs.

Disk footprint may be higher, but memory footprint is definitely lower.
I did extensive testing on that.

> - speed of programs decreases by ~10% because each global variable
> access gets indirect (like pic)

This is so.

> - major blow up of installer size

I fail to see this ?

> 
> > 
> > Packages are IMHO a pre-requisite for any good plugin system.
> > It allows you to enable/disable certain features of a program based on the 
> > particular system you install the package on, without having to recompile
> > your complete application for this particular system.
> 
> Then it's the task of a programmer to design a proper plugin interface.
> A plugin interface based on packages (in the delphi sense) requires that
> the main program and the plugin use exactly the same compiler and rtl.

Yes, of course. I don't see this as a problem, but as a plus, since you
control the environment.

I'm not talking about some audio decoding/encoding mechanism, that is for
babies. I'm talking about hundreds of possible interfaces, highly 
interdependent.

If I had to design a proper plugin interface for my application at work,
I would end up simply re-implementing packages, the interface would be 
HUGE, and would dwarf the implementation code.


> > Lazarus is an IDE and therefore recompilation is IMHO an acceptable solution,
> > since the person using it is a developer (even so, this would be too much asked
> > for most devels in my company) but the same cannot be said for most end-user 
> > applications, OSS or not. For example, I don't think we can expect an end 
> > user to recompile XMMS if he decides to use ogg vorbis files instead of .mp3...
> > 
> > Apart from the recompilation issue, packages allow you to have type-safety in 
> > plugins. A normal dll does not offer this (which is why techniques such as 
> > COM are used on Windows). I could not build my day-time job application if 
> > packages did not exist...
> > 
> > So I do think packages are really a must; I lack the skill to implement them
> > in the compiler, but will be glad to assist in any design issues or even 
> > creating any RTL code that you would need, if this is the problem for you.
> 
> I see only a real use of packages if one doesn't want to distribute the
> source of the IDE like Delphi.

Or, like I said, third party programs for which recompiling by the end user 
is not an option.

Michael.