[Clam-devel] Extending clam: module libraries vs plugins
David García Garzón
david.garcia at upf.edu
Wed Jan 20 11:22:09 PST 2010
On Wednesday 20 January 2010 19:30:51 Pau Arumí wrote:
> 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 :-)
You were right it was pretty straight forward. I just implemented that with
interdependant sndfile and osc and it seems to work well. The only problem we
could get is with headers which contain too many code. That could lead to type
symbol duplications among libs when ones include other. I guess we will face
that problem when addressing spatialization (ie, because of the
ComplexSpectrum which is a port data and a template.)
I abstracted pkg-config files creating in a tool (pc.py) so the only missing
thing to address is the soname and the linknames. If i could extract this and
many of the common scons code among the libs, we could start to split
processing module very fast. (and the scons scripts are getting slimmer and
slimmer!)
With sonames and the like, the main problem right now is that i cannot test
the Mac and Windows variations, but i hope i could ignore that for a while.
David.
More information about the clam-devel
mailing list