Hi Matthias, I was unware of CPack. It certainly sounds like something that might take us further along the road to standardising/automating more of this work.
It would be great if you produce an example. Robert. On Wed, Dec 3, 2008 at 12:04 PM, Mattias Helsing <[EMAIL PROTECTED]> wrote: > Hi Robert, all, > > I have used the CPack program and module from the CMake suite with a > small (but production) project at my company. It didn't use CPack to > it's full extent nor did it ship for other platforms than win32. I > believe that it might be a good and fairly unobtrusive way of defining > packages in our current CMake scripts. Mathieu Marache have commented > on the state of the DEB generator in previous post and that is > certainly a drawback in the short term. An experienced debian package > maintainer (which I am not but willing to try if noone steps up) could > probably get a good start from the current DEB package generator in > CPack though. > > Is CPack an option at all? if so - should I whiip together an example > of how this might be implemented based on the current osg source tree > for you and developers to review? > > cheers > Mattias > > On Thu, Nov 27, 2008 at 3:42 PM, Robert Osfield > <[EMAIL PROTECTED]> wrote: >> Hi Cedric, >> >> On Thu, Nov 27, 2008 at 2:29 PM, Cedric Pinson <[EMAIL PROTECTED]> wrote: >>> I think it's better if you read an example of an ebuild. Because source are >>> compiled when installing package it's easy to setup the cmakelist option >>> when installing the package. In the ebuild example we could add option like >>> gdal, osgal, and what you want. >> >> Thanks for the ebuild example, this is exactly what I need to get on >> an idea of the different needs of packing on different platforms. >> >> >> >> >>> But i think it's not a good idea to create a new package format that could >>> be common with all system. In my opinion the best way to setup package >>> should be to have some vserver that automatically make package. Like a >>> compiling farm. It sound big but could be made step by step. >> >> I'm not thinking about replacing existing packaging system, just >> better supporting >> the ones that are already there. >> >> In the case of windows there is rather a vacuum. How to solve this >> one I can't answer. >> >>> But in fact we just need more maintainer, having those build system limit >>> the amount of work by a human. Just need to check when new version. If we >>> got >>> more maintainers on differents distribution the package problem would not >>> really exist. Maybe we need to find a comunity manager :) >> >> More maintainers isn't just what we require. We need coordinated >> maintenaners, something that is rather lacking right now. It's a case >> of who has the itch goes scratch it for as long as them have time and >> interest. >> >> The maintainers also need to be working off the same general script, >> and to getting required changes back up stream, engaging directly with >> the OSG community. >> >>> I am not sure to understand the big picture you have about packaging so >>> maybe i am wrong >> >> I don't have any strong idea of the ideal system for the OSG and it's >> community, which is why I raised this thread. >> >> My plan is just - Set out a rough goal of wanting to improving the >> packaging situation, gather information, and then tryto resolve some >> workable plan going going. We're at the information gathering point >> right now. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
