Hi J-S, On Thu, Nov 27, 2008 at 3:22 PM, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote: >> Another step would then provide a community mechanism for uploading >> the resulting binary/headers/source "packages" that others can >> leverage. Using the svn repository has been discussed as possible >> location for this. > > Some open repository would be useful, sure, but it would increase the need > for testing, since anyone could replace a given working revision of the > binaries with a non-working one, someone would need to constantly monitor > what's going on on the repository and test the changes...
One couldn't have a totally open system for uploading. Only maintainers would be able to upload. We could include a number of maintainers for each platform. Testing would need to happen of course, and perhaps a holding area for proposed packages would suit this phase. Once a package is tested and approved only then would link to it from the download pages/move it to general public downloads area. > I doubt the upstream maintainers would be willing to maintain files for a > build system they don't use. None of the 7 dependencies I built recently for > our own internal packages use CMake. Each one has their own build system, > which is what makes it a pain. Some build using Visual Studio, some using > nmake. Could we just provide our own external CMake system for them then? Most of these dependencies are complex beasts. > All in all, I'm already doing it once every 4-6 months for work, I > personally don't want to do it any more than that. Mike seems to have a > similar stance. If someone wants to do it feel free. For the most part I would expect dependencies would change rarely. Certainly less often than OSG releases. > Not sure. > > I really think the dependencies are the biggest hurdle. If someone can > streamline the dependencies build process, then at least we would have > dependencies for the 3 major toolsets (VC7.1, VC8, VC9). Building OSG with > those is a piece of cake... Even if we have to do it 6 times (3 toolsets * > (debug + release)). So what options do we have for streamlining the build of the dependencies? > The basic dependencies included in Mike's repo (and I think we should start > with that basic set too) are: > > 1. curl (not necessary but will be useful in the future) > 2. freetype > 3. libjpeg > 4. libungif > 5. libpng > 6. libtiff > 7. zlib (included with libpng) > > Choosing which to build as static libs and which as dynamic libs is a first > decision to take. I would personally go static all the way because there are > more and more applications that add themselves to your PATH on install and > include for example libpng, so your OSG app ends up picking up the wrong DLL > and crashing. But it does increase the plugins' size a bit. I'd be inclined towards static linking of these libs too, the only other alternative is for use to name/version our built dependencies uniquely so as not to risk overlapping with other installs of similar but not quite the same libs. There are also other heavier weight dependencies like COLLADA, OpenVRML, LibXUL/xulrunner that users might want to pull in. The existing Win32 dependency list is really just the core dependencies. How far out one should encompass centrally will something we should leave the community - if volunteers are willing to support a particular dependency package and there is a mechanism for us to provide download space and consistent scheme for naming then we can just leave the door open to this more specialist add ons. I would suggest we come up with set of packages and associated dependencies. There is also the aspect that we may have packages within general packages - for instance OpenThreads could be a package in its own right, and the OSG core libraries could be another package that has minimal dependencies. Then the standard openscenegraph package would contains these packages + the standard dependencies that already exist in the Win32 package. Robert. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
