<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'> <BR>
> Like today, when a libsl update was done as part of the inventory grid<BR>> enablement. It did not go smoothly.<BR><BR>
The problem could have been solved if we had tagged what revision of libsl we had in our repository.<BR>
<BR>
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.<BR>
<BR>> Right now we've got at minimum 5 architectures we need to build .so for:<BR>> MS 32 & 64bit, Linux 32 & 64 bit (intel), Mac. I also noticed someone<BR>> on IRC yesterday trying out Linux on sparc, and I'll be looking into<BR>> Linux on PPC in a couple of months.<BR><BR>
Don't forget that 'Linux' is in it self a bushy tree; also, some are using BSD et.c.<BR>
<BR>
Somewhere, we have to draw the line. And I question if the line should incorporate 'all Linux varieties'.<BR>
<BR>> libsecondlife exists in subversion, which means that it would be<BR>> possible to define an svn external<BR>> (http://svnbook.red-bean.com/en/1.1/ch07s04.html) and build<BR>> libsecondlife as source with the current OpenSim tree (the same approach<BR>> could probably be used for ode).<BR><BR>
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.<BR>
<BR>
Otherwise, libsl could do a breaking change without us knowing it.<BR>
<BR>> However, in order to do this, we'd need to do significantly more with<BR>> our build system. Which means I think we need to revisit the current<BR>> approach on the build system. Right now there is the meta build system<BR>> of Prebuild that generates very basic build files for msbuild and nant.<BR>> Doing something as complicated as native code through this kind of<BR>> system only leads to madness, and something I don't think we should go<BR>> anywhere near.<BR><BR>
I'm totally for re-evaluating prebuild and what we need.<BR>
<BR>> If we were to consider a pure nant based solution here (as nant is cross<BR>> platform) we could actually integrate all of this (and as I'm suggesting<BR>> this approach, would take on the responsibility of making this work).<BR>> It would also open up the ability to do prechecks prior to build (look<BR>> for old mono, missing libraries, etc), and integration of nunit tests.<BR><BR>
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:<BR>
<BR>> I know this degrades some of the experience of MS VS developers. Not<BR>> being one, I'm not sure how to quantify losses on that front vs. gains<BR>> on solving a lot of these other issues we're getting on a regular basis<BR>> on IRC. Hopefully others can comment there.<BR><BR>
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.<BR>
<BR>
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. <BR>
<BR>
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.<BR>
<BR>> This is a proposal for group discussion. Please fire back with<BR>> comments and/or counter proposals.<BR><BR>
Things I think would make the world a better place:<BR>
* Always update binaries in discrete commits, enter the revision that the binary was made from into the log message<BR>
* 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.<BR>
* We provide 'official releases' (which we've been on about for quite some while) that are somewhat tested for several configurations.<BR>
* 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.<BR>
* We don't tell newcomers to 'checkout trunk and build it', but rather to start with some 'official release' and take it from there.<BR>
<BR>
/Stefan<BR>
<BR></body>
</html>