[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
escriure:
> 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
Ok
>
> 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 :-)
P
More information about the clam-devel
mailing list