[Freeswitch-dev] DSO library management issues

[Roman Shaposhnik]

Hi Guys!

I'm getting pretty close to having FreeSwitch up and running
on a SPARC Solaris Niagara box (yeah -- that's the one with
8 physical cores and 32 threads per CPU) which is a good news.
The bad news (at least from my POV) is that I think I've
stumbled upon a particular problem in how FreeSwitch gets
built and packaged for which I don't really have a good
solution. So, in order for me to move forward I have
to make sure that you guys also view this as an issue
and that you'd be willing to address it.

Here's the deal -- its no secret that FreeSwitch depends
on DSOs a *LOT* (in fact, the core of FreeSwitch itself
is a DSO library with a simple wrapper bin/freeswitch
around it). In general I would divide these DSOs into
3 broad categories:

1. Plugin/modules (including CORE)

These guys posses no problem whatsoever -- they get developed
within the FreeSwitch SVN repository, they DO NOT get 
distributed outside of FreeSwitch. They also get built
as part of building FreeSwitch. Always. The only trouble
with them is that sometimes they depend on functionality
available only from external libraries. And that leads
us to the following 2 categories:

2. Well-known external DSO libraries

These are the things you would expect to see on a reasonably
well configured Linux system these days. Things like
/usr/lib/libsqlite3.so or /usr/lib/libapr.so.0. Things which
get developed elsewhere, have their dedicated maintainers 
and packagers. And which are relatively easy to find in
.RPMs or .DEBs.

3. DSO libraries originating from the FreeSwitch project itself.

Now in this category I don't want to discriminate between 
something that Anthony has written (i.e. libteletone) or 
something that just got sucked into FreeSwitch for a lack 
of a better home (i.e. lib/codec/g726). All of these things

Now, why am I telling you all this ? :-) Well, simply because
during my Solaris "porting" effort I've really convinced myself
that we have to have a much better plan for #2 and #3 w.r.t.
building and packaging than what we have in FreeSwitch now.
And here's why:
 
  1. For the #2 I really don't want to sit through the endless
  stream of ./configure ; make ; make install if I already
  have these libraries on my system. What I want instead 
  is a detection mechanism (or --with-<package name>= option
  for a configure script) that would also warn me about the
  version FreeSwitch developers deem to be appropriate for
  each of the packages. 

  2. As for the #3... my take on it is that we shouldn't really
  have #3 in FreeSwitch at all. Every single library from that
  category should either be moved to #1 or to #2. If it ends
  up being in #2 than it has to be moved to a separate SVN repo.

So consider all of the above as a preliminary request for 
opinions and lets hope to make FreeSwitch really portable
and highly configurable at the building and packaging level!

Thanks,
Roman.