[fpc-devel] Dnamic packages support

[Florian Klaempfl]

Michael Van Canneyt schrieb:
> 
> 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.

Well, twice a year, but there are also snapshots, people compile there
code themself etc. Each time you compile and install fpc it will fill
your windows dir or /usr/local/lib with another 50 MB of dlls :)

> 
>> - 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.

Only because dll's/so's are probably being counted shared.

> 
>> - 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 ?

Because we've to deliever also the fpl's?

> 
>>> 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.

Well, but this is mainly abusing packages ;)

> 
> 
>>> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel