Hi Mattias, Thanks for those precisions. I didn't read all the discussion and was not aware of the current customization. Well of course I can build packages by scripting, but that's too bad if I can't use a feature that already does 99% of the job. Anyway, what do you think about the strictly packaging point of view? I mean, what are packaging targets supposed to do in debug?
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 17 Dec 2008 12:47:36 +0100, Mattias Helsing <[email protected]> a écrit: > 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 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
