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