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

[David García Garzón]

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.