[Clam-devel] Extending clam: module libraries vs plugins

Pau Arumí pau.arumi at barcelonamedia.org
Wed Jan 20 10:30:51 PST 2010

El dt 19 de 01 de 2010 a les 23:49 +0100, en/na David García Garzón va
> We had some problems of plugins using processings in other plugins (ie. 
> spatialization using osc...) that we have addressed in a fast and dirty way. 
> Now it seems like the fast and dirty way is a show stopper now so we should 
> address it.
> I was thinking in turning plugins into module libraries (with headers, pc 
> file... just like libclam_procesing and so on) and then adding an almost empty 
> plugin library which just links with the module library. I don't know for sure 
> whether that approach would work but it seems that it would.

Why shouldn't? I'd say it is the same we have now with plugins loading
(normal) clam libraries - and this happens even in ladspa plugins

>  If it works we 
> will have a plan to approach the long time awaited modularization of 
> libclam_processing as plugins but still keeping dependencies among them.

Agree, it's something good to do

> Some decisions should be made on locations and naming. My proposal:
> - headers in include/CLAM/spatialization (or include/CLAM?)

Yes, in subdirectories. We don't have (nor want to have) any control
about the possible file name collisions between plugins.

> - pc file libs/pkgconfig/clam_spatialization.pc
> - library libs/libclam_spacialization.so.1.4.0
> - plugin libs/clam/libclam_spatialization_plugin


> Some other implications:
> - Installing the headers
> - Building the pc file
> - Building the empty plugin
> - Considering soname and versioning in plugins

> Any comments?

Seems pretty straightforward :-)


More information about the clam-devel mailing list