[fpc-devel] Dnamic packages support

[Marco van de Voort]

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

Yes. And if my 500GB disk will be filled up with snapshots in
500GB/50MB=10000 days, I'm sure in 27 years, the same HD will be a lot
cheaper.

Aside from the fact it makes sense to routinely install compatible versions.
Keep release + 1 snapshot just like with the compiler.

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

To be honest, all this diskspace/memory stuff is totally uninteresting.
Packages are about dividing the Pascal program up in blocks, with parts
being compilable AFTER the main program, without a lot of additional demands
(or need for control) on the interfaces between the packages.

Don't get too worked up about plugin architectures in the AutoCAD sense. In
practice it is way simpler, like only shipping one BPL to a custom if he
@(#*@$ paid for it. This means you can have one main binary, in which a hand
full of acquisition BPLs register themselves. 

> >> - major blow up of installer size
> > 
> > I fail to see this ?
> 
> Because we've to deliever also the fpl's?

If it really is that of a problem, you only deliver them using a optional
package.

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

No it is not. If the interface is not a focus of your design, it is a waste
of time to spell it out, and keep the packages independant programs.

Most notably since that fails miserably on Linux atm, since RTL duplication
isn't handled very well.