[Opensim-dev] so many dll's, so little time

[dan miller]

Turns out ODE's actual source code is < 3 megs; the rest is mostly a big
game demo.

As a test case, I incorporated openjpeg-libsl into trunk/libraries, compiled
it on windows & ubuntu, and put those binaries into bin.  I plan to do this
with all the native libs, which AFAIK are just ODE and SQLITE.

I won't be shy about trimming & patching these versions as necessary for
opensim stability.  I realize this is not a perfect scenario but it sure
beats running native code that no one remembers compiling or downloading.

I strongly urge the C# experts out there to do the same thing with all the
managed libraries that we don't have source for.  I don't have the .net
skills to take the few files out of Axiom's .5-gig release and figure out
how to compile them properly for inclusion in opensim.  I tried a bit with
Axiom (couldn't get it to compile without errors), and with libsecondlife
(couldn't compile a version without runtime errors).  I'm going to focus on
native, C++ code since that's something I am familiar with.

-danx0r


--- Michael Wright <michaelwri22 at yahoo.co.uk> wrote:

> With Axiom, we only use the math library, so I think we only need to
> include the source for that library (which is a small library). Of course
> this don't help with the ODE problem/size.
> 
> dan miller <danbmil99 at yahoo.com> wrote: this looks like exactly the right
> approach.  Keep in mind that ODE is 40
> megabyes, so we're talking about 80 megs right there (40 for the vendor
> drop, 40 more for trunk).
> 
> Take Axiom.  It uncompresses to almost _400_ megabytes!  Granted most of
> that is some demo game with assets, but that's what they have in their
> source drop.  It doesn't seem feasible for everyone to have two copies of
> that in their trunk directories!  At this rate, with over 20 3rd party
> libs,
> svn checkouts will soon be several gigabytes.  
> 
> I think the answer is to use the vendor drop concept, but in a separate
> project, opensim-libs.  We can simplify the procedure in the case where we
> don't patch anything, by just using the vendor's drop directly.  If we
> need
> to patch, we do as the article says and create a separate, patched
> version,
> and merge whenever we need to absorb a new vendor release.
> 
> The final step after building everything would be to create a .zip file
> with
> just the DLL's necessary to run opensim (a couple megabyes).  Casual users
> would just download the proper zip file and be ready to get on with their
> lives.
> 
> -danx0r
> 
> 
> --- Stefan Andersson  wrote:
> 
> > I think we should use 'vendor branches' 
> > http://svnbook.red-bean.com/en/1.1/ch07s05.html
> >  
> > I've already done a prototype .build that first builds a target
> consisting
> > of the native dlls, then the main opensim build.
> >  
> > Such a target can be very specific and hand-crafted; on vs we'd just
> make
> > prebuild include a couple of non-generated vs projects (also
> hand-crafted
> > and not necessarily c#) maybe in a run-on-the-side solution.
> >  
> > That would be win-win for all environments, I'd say.
> >  
> > /Stefan
> >  
> > 
> > 
> > 
> > > Date: Wed, 17 Oct 2007 11:18:07 -0700> From: danbmil99 at yahoo.com> To:
> > opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] so many dll's,
> so
> > little time> > The major issue for me is that we are in some cases
> > apparently depending on> binary code without access to the correct
> source
> > versions. This could> become quite an exercise in forensic compilation
> if
> > we don't sort it out> now.> > What I plan to do is try to acquire the
> > source code versions that we believe> most closely match the DLL's we
> have
> > in subversion, and get them all into> trunk/libraries. Then we can
> compile
> > them and test them against the> codebase, and work through any issues
> > until we have the ability to compile> and run opensim 100% from source
> > code. I'm not advocating we force all> developers to deal with this;
> just
> > a few of us core ppl to get it straight,> then we provide manna from
> > heaven to the rest in the form of precompiled> binaries. Eventually, all
> > the C# code should be easily incorporated into> nant/prebuild (right?).
> > The native libs will always be a bit trickier, but> the same approach
> > should work -- collect the code, keep it in> trunk/libraries, and
> provide
> > a mechanism for casual users to get binaries> appropriate to their
> > platform.> > -danx0r> > > -danx0r> > --- Tleiades Hax 
> > wrote:> > > >> > > I'm not sure that I understand the option here. Are
> you
> > proposing to> > > write your own XML-RPC implementation for login?
> XML-RPC
> > is managed> > > code right, is there any reason that isn't intrinsically
> > cross platform> > > already (or did I miss that part)?> > >> > > > > > I
> > think it is quite obvious, by examining the sourceforge site for the> >
> > project, that it is no longer being actively maintained. I guess the> >
> > majority is for using an external component for handling the logon
> > method.> > I'm ok with that.> > >
> > _______________________________________________> > Opensim-dev mailing
> > list> > Opensim-dev at lists.berlios.de> >
> > https://lists.berlios.de/mailman/listinfo/opensim-dev> > > >
> > _______________________________________________> Opensim-dev mailing
> list>
> > Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev>
> _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
>        
> ---------------------------------
>  For ideas on reducing your carbon footprint visit Yahoo! For Good this
month.> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>