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

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 :-)

> > 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 
stopping me from using FPC/Lazarus for my daytime job. All else is 
covered or can be covered with a minimal amount of work.

Michael.