[Opensim-dev] 3rd party libs and build system revisited

[Stefan Andersson]

> Like today, when a libsl update was done as part of the inventory grid> enablement. It did not go smoothly.
The problem could have been solved if we had tagged what revision of libsl we had in our repository.
 
Also, I was quite naive and took the risk of just getting 'head' on libsl, building and shipping it as it worked fine for me; and I have no way to test for Linux/Mac compatibility.
 > Right now we've got at minimum 5 architectures we need to build .so for:> MS 32 & 64bit, Linux 32 & 64 bit (intel), Mac. I also noticed someone> on IRC yesterday trying out Linux on sparc, and I'll be looking into> Linux on PPC in a couple of months.
Don't forget that 'Linux' is in it self a bushy tree; also, some are using BSD et.c.
 
Somewhere, we have to draw the line. And I question if the line should incorporate 'all Linux varieties'.
> libsecondlife exists in subversion, which means that it would be> possible to define an svn external> (http://svnbook.red-bean.com/en/1.1/ch07s04.html) and build> libsecondlife as source with the current OpenSim tree (the same approach> could probably be used for ode).
We would definitively not be doing an external to 'head', but to some specific revision. We would still have to do a manual update and thorough testing on all supported platforms before we changed that external.
 
Otherwise, libsl could do a breaking change without us knowing it.
> However, in order to do this, we'd need to do significantly more with> our build system. Which means I think we need to revisit the current> approach on the build system. Right now there is the meta build system> of Prebuild that generates very basic build files for msbuild and nant.> Doing something as complicated as native code through this kind of> system only leads to madness, and something I don't think we should go> anywhere near.
I'm totally for re-evaluating prebuild and what we need.
> If we were to consider a pure nant based solution here (as nant is cross> platform) we could actually integrate all of this (and as I'm suggesting> this approach, would take on the responsibility of making this work).> It would also open up the ability to do prechecks prior to build (look> for old mono, missing libraries, etc), and integration of nunit tests.
I have no beef with nant, it's an excellent build environment for automated builds. The concept of building more from source sits well with me, but:
> I know this degrades some of the experience of MS VS developers. Not> being one, I'm not sure how to quantify losses on that front vs. gains> on solving a lot of these other issues we're getting on a regular basis> on IRC. Hopefully others can comment there.
It doesn't just degrade it, it would completely demolish it. As an integrated IDE VS uses project information for cross-referencing when doing operations on code; it discerns binary references from project references, so that you can immediately follow code paths within the solution; it uses the information to calculate the scope of a refactoring et c.
 
Working with separate files that is not part of a project that is not part of a solution would in effect cut the vs developers out of the loop. 
 
We have worked VERY HARD to make a peaceful and fruitful co-existence between MS/.NET/VS users and Linux/Mono/vi users; Although not perfect, Prebuild is the best compromise we've found so far.
> This is a proposal for group discussion. Please fire back with> comments and/or counter proposals.
Things I think would make the world a better place:
* Always update binaries in discrete commits, enter the revision that the binary was made from into the log message
* We can ship binaries for several configurations in separate x64/Linux directories; it would be up to whoever found out that a binary has to be rebuild for their environment to make sure it's done.
* We provide 'official releases' (which we've been on about for quite some while) that are somewhat tested for several configurations.
* We and agree that trunk can be functionally broken (it should always build, but might not run) for a certain configuration, and agree to help each other in fixing it. The 'you broke it, you fix it' attitude is asocial, childish and counter-productive.
* We don't tell newcomers to 'checkout trunk and build it', but rather to start with some 'official release' and take it from there.
 
/Stefan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20070928/49e3ef42/attachment-0001.html>