Hi Robert, On Fri, Dec 12, 2008 at 1:29 PM, Robert Osfield <[email protected]> wrote: > Hi Mattias, > > I've just been playing with build the various packages and a couple of > potential usage look like they might loom up. > > First up is that when because we have separate packages then all > unpack into separate directories, which would force end users to > manually install the files from each individual package to be able to > use them. One could just unpack packages in one directory and then > set env vars to pick them up.
yes. I picked that up too and posted a question on the cmake mailing list about this. I should have reported this but I have tried many combinations of vars to change this too. My post didn't get any response at all so I guess the situation is much like the situation with osg - I need to download, understand, compile and submit improvements to cmake. It seems like the cpack team is currently focused on visual installers for projects that are structured like cmake itself (which is understandable). What we want to do is a bit out of their scope right now so I might need to create this functionality myself. The Cpack.cmake script is basically streamlined to fit an application type project and will generate CPackConfig.cmake and CPackSourceConfig.cmake wheteher you like it or not. Actually - initially I had opted to not include CPack at all but pulled it in because it does good things too. Now about our question one could create OpenSceneGraph.tgz packages and rename them but making cmake support what we want to do is fr better IMO. > > Second issue is that libopenscenegraph contains just plugins, and only > really makes sense being called openscenegraph if it's actually > contains enough of the openscenegraph to be functional. This isn't an > issue that you've introduced, rather it's a manifestation of my > thought that having a pure openscenegraph-core was a good idea. I > think perhaps we should just make the standard plugins including the > ones with external dependencies like freetype, tiff, jpeg etc. as > dependencies, and package it all under libopenscenegraph and > libopenscenegraph-dev. > > Merging libopenscenegraph-core and libopenscenegraph would meant that > the standard openscenegraph package has more external dependencies > that is absolutely necessary for a minimal OSG install, but perhaps > that just fine - if users really do need to be that constrained with > their dependencies they can always roll their own binaries. thats fine and this is a good improvement of an first idea using an initial implementation > > Could you go ahead and merge libopensenegraph-core into libopenscenegraph? I see you've done this already. great! > > A final thought is that about packaging and management of > dependencies. debian packaging has this built in, so if I grab > libopenscenegraph-dev I get libopenscengraph automatically. Is there > anything in cpack that goes to address this side of things? Cpack does no magic like apt does, but we can provide files/strings that will generate good debian packages with currect dependencies/recommendations and so forth. However if I/we get to improve this script to generate visual installers (nsis/package maker?) the dependencies on other components can be put in that installer. This is one benefit of an installer. Further - one can set up an installer to download only what the user wants. This would a tiny installer which only downloads osg-core if thats what the user wants but the entire source and choosen plugins. The latter requires a strong server of course. Mattias > > 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
