<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:courier, monaco, monospace, sans-serif;font-size:12pt"><DIV>There are a few good explanations (I hope).</DIV>
<DIV> </DIV>
<DIV>I have chosesn to build all of the code used in the program for a few reasons:</DIV>
<DIV> </DIV>
<DIV>1) To ensure proper configuration and versioning.</DIV>
<DIV> a) We have no control over what options the default system libs </DIV>
<DIV> were built with (thread saftey options etc).</DIV>
<DIV> b) As a side-effect of our extensive push on our dependancies,</DIV>
<DIV> we often need the code to be modified to work properly </DIV>
<DIV> due to necessary modifications or bugfixes that only exist</DIV>
<DIV> in our private tarball while we wait for a new version to be released. </DIV>
<DIV> c) Most distros do not provide cutting edge releases of libraries</DIV>
<DIV> which be necessary due to results from sub-reason (b)<BR> </DIV>
<DIV>2) To create a atonomous environment.</DIV>
<DIV> a) The defualt install prefix is /usr/local/freeswitch all of the depends</DIV>
<DIV> are installed in this dir so you can subsequently tar up that directory</DIV>
<DIV> and move it to another machine without installing it again.</DIV>
<DIV> </DIV>
<DIV> b) Some systems have slightly different versions of the same</DIV>
<DIV> libraries that do not co-exist well we never need to look outside</DIV>
<DIV> of our own lib dir for these libraries.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>I am fairly concerned with making huge initiatives in the build process</DIV>
<DIV>during a time where I am still coding 12 hours a day on the core but I am open</DIV>
<DIV>to improvement as long as the tangent does not impeed my development effort.</DIV>
<DIV>Imagine if someone wanted to install superior scafolding while the guy is on top of it building the house still. Once development shifts to higher level</DIV>
<DIV>stuff my concerns will most likely subside.</DIV>
<DIV> </DIV>
<DIV>One bright note is if you dont watch during the endless stream of ./configure make ; make install, it goes faster (a watched pot never boils) =D</DIV>
<DIV>And that only happens the first time, subsequent builds go much faster.</DIV>
<DIV> </DIV>
<DIV>I am truely anxious to see what happens on this super sun box</DIV>
<DIV>and I'd like to thank you for your efforts and your valuable time I really</DIV>
<DIV>appriciate your help.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Anthony Minessale II<BR><BR>FreeSWITCH http://www.freeswitch.org/<BR>ClueCon http://www.cluecon.com/<BR><BR>AIM: anthm<BR>MSN:anthony_minessale@hotmail.com<BR>JABBER:anthony.minessale@gmail.com<BR>IRC: irc.freenode.net #freeswitch</DIV>
<DIV><BR>FreeSWITCH Developer Conference<BR>sip:888@66.250.68.194<BR>iax:guest@66.250.68.194/888<BR>googletalk:freeswitch@gmail.com<BR>pstn:712-432-7800</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif"><BR><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Roman Shaposhnik <rvs@sun.com><BR>To: freeswitch-dev@lists.freeswitch.org<BR>Sent: Saturday, September 30, 2006 1:02:01 AM<BR>Subject: [Freeswitch-dev] DSO library management issues<BR><BR>
<DIV>Hi Guys!<BR><BR>I'm getting pretty close to having FreeSwitch up and running<BR>on a SPARC Solaris Niagara box (yeah -- that's the one with<BR>8 physical cores and 32 threads per CPU) which is a good news.<BR>The bad news (at least from my POV) is that I think I've<BR>stumbled upon a particular problem in how FreeSwitch gets<BR>built and packaged for which I don't really have a good<BR>solution. So, in order for me to move forward I have<BR>to make sure that you guys also view this as an issue<BR>and that you'd be willing to address it.<BR><BR>Here's the deal -- its no secret that FreeSwitch depends<BR>on DSOs a *LOT* (in fact, the core of FreeSwitch itself<BR>is a DSO library with a simple wrapper bin/freeswitch<BR>around it). In general I would divide these DSOs into<BR>3 broad categories:<BR><BR>1. Plugin/modules (including CORE)<BR><BR>These guys posses no problem whatsoever -- they get developed<BR>within the FreeSwitch SVN repository, they DO NOT get
<BR>distributed outside of FreeSwitch. They also get built<BR>as part of building FreeSwitch. Always. The only trouble<BR>with them is that sometimes they depend on functionality<BR>available only from external libraries. And that leads<BR>us to the following 2 categories:<BR><BR>2. Well-known external DSO libraries<BR><BR>These are the things you would expect to see on a reasonably<BR>well configured Linux system these days. Things like<BR>/usr/lib/libsqlite3.so or /usr/lib/libapr.so.0. Things which<BR>get developed elsewhere, have their dedicated maintainers <BR>and packagers. And which are relatively easy to find in<BR>.RPMs or .DEBs.<BR><BR>3. DSO libraries originating from the FreeSwitch project itself.<BR><BR>Now in this category I don't want to discriminate between <BR>something that Anthony has written (i.e. libteletone) or <BR>something that just got sucked into FreeSwitch for a lack <BR>of a better home (i.e. lib/codec/g726). All of these things<BR><BR>Now, why
am I telling you all this ? :-) Well, simply because<BR>during my Solaris "porting" effort I've really convinced myself<BR>that we have to have a much better plan for #2 and #3 w.r.t.<BR>building and packaging than what we have in FreeSwitch now.<BR>And here's why:<BR><BR> 1. For the #2 I really don't want to sit through the endless<BR> stream of ./configure ; make ; make install if I already<BR> have these libraries on my system. What I want instead <BR> is a detection mechanism (or --with-<package name>= option<BR> for a configure script) that would also warn me about the<BR> version FreeSwitch developers deem to be appropriate for<BR> each of the packages. <BR><BR> 2. As for the #3... my take on it is that we shouldn't really<BR> have #3 in FreeSwitch at all. Every single library from that<BR> category should either be moved to #1 or to #2. If it
ends<BR> up being in #2 than it has to be moved to a separate SVN repo.<BR><BR>So consider all of the above as a preliminary request for <BR>opinions and lets hope to make FreeSwitch really portable<BR>and highly configurable at the building and packaging level!<BR><BR>Thanks,<BR>Roman.<BR><BR><BR>_______________________________________________<BR>Freeswitch-dev mailing list<BR>Freeswitch-dev@lists.freeswitch.org<BR><A href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target=_blank>http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</A><BR>UNSUBSCRIBE:<A href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target=_blank>http://lists.freeswitch.org/mailman/options/freeswitch-dev</A><BR><A href="http://www.freeswitch.org/" target=_blank>http://www.freeswitch.org</A></DIV></DIV><BR></DIV></div><br></body></html>