[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:
>>>
>>>> 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 :)
> 
> Snapshots are of course not suitable; We don't support them in the first place.
> I also don't use development builds or Betas of Borland, although I could.
> 
> I have 1 set of BPLs on my system. Works excellent.

Because you use only one delphi version.

> 
> And for an application that needs to change compiler version - something
> that happened on my day-time job once in 8 years, this is not a problem.
> 
>>>> - 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.
> 
> No, because they have a single memory area.

?

> 
>>>> - 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?
> 
> The package system will solve this nicely, because we'll only
> distribute sources anyway. By the end of this year, I hope that
> you'll be convinced of that :-)


I fear somehow the deploying and maintainance of packages because of the
reasons mentioned: size, versioning, different code generation etc.

> 
>>> 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 ;)
> 
> On the contrary, it is using them for what they were designed to 
> accomplish.
> 
> Make no mistake:
> I am not the only one using them like that. Beside my own articles
> about it, there have been several description of such systems in 
> e.g. Toolbox.
> 
> Look, I don't try to convince you that Lazarus or FPC should make
> extensive use of packages - we worked years without it and we worked
> very well, but you should also be open to the idea that there are 
> areas where they are simply a very good thing, making development
> much easier. Not everyone is a seasoned compiler developer like we 
> are, and packages make it possible for less-educated developers to
> participate in more complicated architectures, because they don't have
> to worry about creating interfaces, ref counting, setting memory managers 
> and whatnot. I cannot even begin to explain to some of my collegae what 
> an interface is, they even barely understand classes. And because of 
> Delphi's RAD approach and the use of packages, they don't have to...
> 
> Packages and the missing TClientDataset are the only 2 remaining things 

See irc ;)