Hi Sukender, On 12/17/08, Sukender <[email protected]> wrote: > Hi Robert, > > I understand your point of view, and you're right about saying that constant > testing is essential for OSG. But in another hand, if someone develop with a > library based on OSG (say mine ;p ), that developper may not want to get the > OSG sources and compile it himself when going from release to debug. > Moreover, from a strictly packaging point of view, it seems unnatural to > have releases binaries when building in debug. And if you don't compile the > release version before, would then the package be empty since no release > targets have been compiled (as explained in my previous mail)? > > So maybe ther would be a compromise? My suggestion is that online packages > should *all* be release ones. But the ability to build debug packages sounds > very interesting for me since my library is not updated as often as OSG; and > maybe others would also find it useful from time to time. What do you think > about it?
Without having looked at your problems closely what you want is harder than saying "let's do it this way". Very much of this packaging is relying on cmake/cpack functionality. We just ask it to pack what we earlier told it to install. Making the separation of release and debug in packages may for example require us to revert our current customization (on win32) of not using "debug" and "release" subdirectories below the lib and bin folders. Making packages is not going to to be something you do every day. And most people should never have to do it. Also it is typically something that you script. So I guess I'm with Robert on this. Making debug packages is still easy. You just need to double check that the package you got contains what you expected, upload it and wait 2 months for the next major release Mattias > > Sukender > PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ > > > Le Wed, 17 Dec 2008 10:35:34 +0100, Robert Osfield > <[email protected]> a écrit: > >> Hi Guys, >> >> I'm inclined to just provide packaged binaries for the main targets >> rather than worry about all the various different options. I'd even >> go as far as say just providing release build packages would be fine. >> >> The OSG itself isn't that difficult to build, and OSG users all should >> be capable of pulling down the sources and building their own version >> of the OSG. The binaries of really help out with quick evaluations of >> the OSG and for helping redistribution of binaries/libs with >> applications or as part of central repositories. >> >> For day to day development we actually want osg users to be compiling >> from source and testing out latest versions as this is how we get >> people to test and debug the OSG, which in turn is how we keep the >> quality of our software high - this constant testing. Over reliance >> on binaries during the development cycle will lead to less of the >> community testing the source build and runtime, which is not something >> we really want to encourage. >> >> Robert. >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
