Dynamic loading of packages

[mikiwoz]

Maybe a question that has been already answered, but cannot find it anywhere on forums:
When is dynamic loading of packages (i.e. without the need to recompile Lazarus) planned to be available, if at all?

Cheers
mike

[Vincent Snijders]

It is planned to be available once fpc supports it.

Packages are planned for fpc 2.2.
See http://www.freepascal.org/future.html for fpc's plans.

[mikiwoz]

Thx, didn't know that.

Cheers
mike

[tk]

What is the development status of this feature?

No word about packages found on the FPC plans page.

I am working with many packages inclusive improving mine ones, would really appreciate the delphi manner which is much faster.

Or how to prevent steady recompilation of Lazarus?

Thank you

[BigChimp]

If you have looked and not found anything the answer seems obvious. AFAIK, there's no current work on it being done.

You could ask on the fpc-devel mailing list - I'm sure the compiler guys will have a definitive answer though...

IMO recompilation is not too bad as long as you keep your debug settings the same, only a small part will need to be recompiled. Then again, I'm not a package developer so probably don't run into the issue nearly as much as you...

[marcov]

Sven has looked at dynamic packages. Note that is something else then actually using it in Lazarus.

I would also be very careful projecting Delphi experiences to Lazarus in this regard, some of the internals are simply different. (like having an external compiler)

[skalogryz]

In many cases you don't need an actual "dynamic package".

All you probably need is to have a component available in the Forms Designer and Object Inspector.

Well, what could happen in this case is that a description of the object could be loaded to the IDE from external resources, i.e. a description file, rather than reading RTTI information.

The description file, could indeed be generated based on RTTI information. But for that purpose there's no need to recompile the whole IDE, instead some "rtti generator template" could be recompiled with the sources.

[marcov]

In many cases you don't need an actual "dynamic package".

All you probably need is to have a component available in the Forms Designer and Object Inspector.

True. If you don't need icons, property editors etc. But does it really pay to have two different schemes and umpteen forms of metadata? Even if we don't do designtime compiled packages, I rather recompile the IDE, the problem is not THAT big to try to optimize it with a hackety minimalistic solution.
 

[skalogryz]

True. If you don't need icons, property editors etc.

Well, icons are not really an issue. Especially if available as external files.
Property Editors are indeed more complicated to be implemented as external applications.

But does it really pay to have two different schemes and umpteen forms of metadata?

No matter what the form is (or how many forms), there's only one schema in the end.

Even if we don't do design-time compiled packages, I rather recompile the IDE, the problem is not THAT big to try to optimize it with a hackety minimalistic solution.

I've ran into an issue myself. I could not compile a package for x86_64 IDE, so had to build i386 IDE.
Another small benefit, is that packages could get rid of "design-time" code.

[marcov]

True. If you don't need icons, property editors etc.

Well, icons are not really an issue. Especially if available as external files.

Many loose files contribute to slow startup. Same with external applications for common tasks. Integrated Development Environments(IDE) were created to combat that.

Property Editors are indeed more complicated to be implemented as external applications.

I don't see any other solution to that. And more importantly, I don't see a problem big enough to even consider it.

Even if we don't do design-time compiled packages, I rather recompile the IDE, the problem is not THAT big to try to optimize it with a hackety minimalistic solution.

I've ran into an issue myself. I could not compile a package for x86_64 IDE, so had to build i386 IDE.

Fix the package would be more logical.

[skalogryz]

Fix the package would be more logical.

True, except for the cases of a package being OS specific, and I guess dynamic packages won't help to resolve the issue as well, since they're os dependent.

Property Editors are indeed more complicated to be implemented as external applications.

I don't see any other solution to that. And more importantly, I don't see a problem big enough to even consider it.

That's a typical task for "extensible applications". With Scripting languages (Pascal script?) as a typical alternative to using dynamically loaded plugins.

[marcov]

True, except for the cases of a package being OS specific,

The design package alone, while the runtime is not. But 9 to 10 that that package then does more than can be done without. (e.g. custom guis for the prop edits)