Hi!

Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC. (At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :).

Cheers,
Willi

P.S.: Way back in time, I did some "investigation" on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only).

Hi,
I think you can start by reading http://wiki.freepascal.org/packages and http://wiki.freepascal.org/shared_library .

Regards
Žilvinas Ledas

In our previous episode, Willibald Krenn said:

Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC.

To my best knowledge: no.

(At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :).

Some resources you might want to have a look at:

- Maybe not necessary if you know them already intimately, but I kept a bit of a brainstorm on packages here:
http://wiki.freepascal.org/packages

- a bugreport about creating shared libraries using the makefiles: http://bugs.freepascal.org/view.php?id=12492 with 45 comments with a lot of detail.

P.S.: Way back in time, I did some "investigation" on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only).

I don't know if this is necessary for packages, BUT: As far as I know FPC doesn't add the parameter name to the mangling, only the type. Moreover, the type is bare, iow not qualified with unitname. I don't know the status of the other details (like calling conventions).

aparantly you beat me to it, but I was planning on compiling a mail like this one later today (at home).

Besides you (an me), is there anyone else interested in implementing this? My angle (besides from the obvious dynamic pluginsystem vs "the lazarus/*nix FOSS way" aka rebuild everything when you want something included) is that there are some additions to RTTI that need to be done as well regarding packages, units en the relationships with current RTTI and startup-initialization.

I would be nice to know who wrote/compiled the packages page in the fpc wiki and to get in contact with ppl that want to discuss/implement "delphi packages".

kind regards,
Dimitri Smits

Dimitri Smits wrote

My angle (besides from the obvious dynamic pluginsystem

This is why there is no work on a packages system for FPC: there are simply too much different versions around. While Delphi has at most one release per year, FPC/Lazarus has more or less every day a new version. A package compiled for FPC/Lazarus built from todays sources will mostly not work with a program compiled from yesterday sources.

If you want a plugin system, you should create a defined API for this plugin system but not depend on the moving target of packages.

The use of packages for FPC is simply much less than for Delphi.

In our previous episode, Dimitri Smits said:

Note that I don't hold library packages for Lazarus as very desirable.

aka rebuild everything when you want something included)

Note that I have never heard anybody complain about the quick lazarus startup time relative to Delphi. That is the flip side of dynamic packages !!!

I would be nice to know who wrote/compiled the packages page in the fpc wiki and to get in contact with ppl that want to discuss/implement "delphi packages".

I did.

This is why there is no work on a packages system for FPC: there are simply too much different versions around. While Delphi has at most one release per year, FPC/Lazarus has more or less every day a new version.

Well, but not that much stable releases, I suppose. :) I am sure that Delphi has/had quite a few internal versions too...

A package compiled for FPC/Lazarus built from todays sources will mostly not work with a program compiled from yesterday sources.

Even if you divide up your code into packages (Delphi ones), you are not forced to compile with packages 'enabled'. Hence daily builds can stay perfectly static as is. However, you'd gain the option for stable releases to have modules. Said that, within open source, packages are probably less useful than in the commercial-closed source world.

If you want a plugin system, you should create a defined API for this plugin system but not depend on the moving target of packages.

I tried that once with Delphi/VCL (and mdi-child forms): It was horrible to maintain and utterly difficult to debug. Packages just let you use classes (forms etc.) from within dlls so much more easily. Besides, you can still do your own API on top of packages ;-)

The use of packages for FPC is simply much less than for Delphi.

This is probably true. However, from an end-user's perspective, I would not say that I do a fpc/lazarus re-build every day. I'd rather stick with some stable version and concentrate my own (application) code.

But I guess, my main motivation on this is "fun on hacking a compiler feature" ;-)

Cheers,
Willi

The best motivation we can imagine :-)

Michael.

No.

True but building releases with optional dyn. has another disadvantage: they increase heavily the distribution size and people are already complaining now about download size.

But I guess, my main motivation on this is "fun on hacking a compiler feature" ;-)

That's a very good point :) However I fear implementing packages is one of the less fun features.

I really am wanting something for my core objects so they can be loaded and the service application across different network nodes is costly, time and CPU intensive.

Please do (at least) two separate projects:

- "Plugins" (easy to use FPC->FPC DLLs / .so's with additional informations such as Delphi "Runtime-Packages")
- "Unit collection" (development packages with or without source code).

I hate calling both the same name ;).

-Michael

Hans-Peter Diettrich wrote

IMO the implementation of Delphi packages in FPC depends on two things: the resources required for such an implementation, and the chance for closed-source libraries. When we want to disallow or even discourage closed-source FPC projects

I think the modified LGPL clearly shows that we don't want discourage closed-source software.

In our previous episode, Hans-Peter Diettrich said:

I was only talking about packages in Lazarus (designtime). I don't see a large benefit, and versioning an insurmountable problem.

I think plugin uses for users are a perfectly fine application. Actually that is IMHO pretty muchthe only reason, since I'm no firm believer that in this day and age the possible filesize savings are still that important. (and even less so when this finally reaches production)

Unfortunately, this (packages) is a feature that afaik requires heavy compiler and deep RTL work. Moreover the inner workings of the Delphi package are not very well documented (which is why I created the wikipage)

I don't see any connection why the situation with packages would be any different, licensewise, from the current situation with EXEs.

... Most notably since a EXE+packages is essentially just an EXE fragmented over multiple parts.

Note that I have never heard anybody complain about the quick lazarus startup time relative to Delphi. That is the flip side of dynamic packages !!!

Right, but that's no reason for not using packages somewhere else.

Delphi packages have been invented as an improvement of DLLs, to make them type safe etc., and this idea can be used with shared libraries on any platform.

IMO the implementation of Delphi packages in FPC depends on two things: the resources required for such an implementation, and the chance for closed-source libraries. When we want to disallow or even discourage closed-source FPC projects, I see no urgent need for implementing Delphi packages.

DoDi

E.g. for a closed source IDE packages are essentially.

In our previous episode, Florian Klaempfl said:

Then you touch the Lazarus license (GPL), still not FPC's.

Moreover, I already said I don't think binary design packages (proprietary or not) are very practical for Lazarus.

Not Lazarus but just some hypothetical 3rd party IDE.

I don't see any connection why the situation with packages would be any different, licensewise, from the current situation with EXEs.

Licenses are of no concern here. How (what files) can somebody provide closed-source plug-ins (or the like), when their integration into some other application requires source code?

DoDi