Load extensions/modules at runtime

Josef Weidendorfer Josef.Weidendorfer at gmx.de
Tue Feb 22 17:20:43 GMT 2005


Hi,

On Tuesday 22 February 2005 16:24, Mauricio Bahamonde wrote:
> Loading extensions/modules at runtime, and NOT at compile time.
> It's very uncomfortable to have to recompile an app to enable a feature.

That depends on the view: as user, you get packages from your distributor and 
don't compile yourself.

But you have a point: Either the distributor compiles all plugins into one 
package, and installing the package will install all plugin dependendies, 
too.
Probably you don't want to get gstreamer installed when you only want to have 
amarok using arts. So the distributor can split up amarok into smaller 
packages for the different plugins. Now if you change your mind and install 
gstreamer after amarok, the gstreamer plugin of amarok will be missing on 
your system, and you probably never know that gstreamer support exists at all 
in amarok.

Yes, this can be a problem, and a runtime dependency would be better.

> possible? I've been thinking this for a couple of days, but I think this is
> not actually possible because the plugin includes a header of the
> program/library and if it's not present, the plugin will not be compiled,
> then the program obviously won't have the support for that plugin.

Runtime dependency is easy possible for command line interfaces: If gstreamer 
support would be possible by calling an external binary, no problem (e.g. 
with streaming raw wav data into stdin of that binary).
If gstreamer would provide some kind of DCOP interface, the same holds.

If the interface is an API with header file and library linking, it is more 
difficult: you have to include a copy of the header file of the gstreamer API 
with amarok sources (no problem?).

Hmmm.... actually, if the plugin itself is a shared lib, the linker can link 
the plugin without external libraries (IMHO). But at runtime this will fail 
if a dependent shared lib is not installed.

But the plugin can dlopen the needed shared libs. If libraries are not 
installed, it even should be possible to return something like "Plugin X 
disabled because dependent library Y not installed". This mechanism could be 
part of kdelibs.

So you are right, it should be possible. Something for KDE4 indeeed.
IMHO the same technique optionally is used in newer QT with the OpenGL 
dependeny.

Cheers,
Josef

>
> Greetings,




More information about the kde-core-devel mailing list