Hi J-S, On Thu, Nov 27, 2008 at 3:01 AM, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote: > I agree, the biggest challenge for Windows is the number of different > toolsets available. What we call the "build matrix" is just too large to be > doable. There's MSVC7.1, MSVC8, MSVC9, cygwin, mingw. Then there's debug, > release, relWithDebugInfo, ... Then there's static, dynamic, dynamic but > with statically linked dependencies...
There isn't any way we can cover all the different combinations, the best we can do is try and come up with a scheme where the dependencies, and the OSG components can be built as seamlessly as possible by end users. 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. > On Linux, what's the strategy? Do we aim to offer binaries for all distros, > some distros, the most popular, those which are used by the packagers? I > think our strategy for distros on Linux could be transposed to be our > strategy for toolsets on Windows. Dependencies are much easier to deal with thanks to package managers and great repositories. The part that needs wrapping up under Linux is making it easier for the distro's maintainers to pick up the OSG sources and then generate the required binaries that they wish to distribute. The later is similar to needs of Windows. We could possible manage the packages ourselves and let the distro's grab these, or just provide the scripts for them to use. What I'm not currently happy about with the present status quo under Linux is that there is little or no coordinate upstream from the distro's to OSG development or granularity/versioning/naming of packing. What we should have is scheme that works well for the distro's but is consistent across them so end users know that can grab dependencies from a rpm or deb repository without any worries about them contain different components/dependencies. > As you've said, in the past only the dependencies and binaries for VC8 SP1 > were available. That was the most popular, and that was what Mike had / was > willing to take the time out of his schedule to provide. > > That touches on the issue of volunteering time. As you said, people surely > have built the VC7.1 and VC9 dependencies, but they just haven't put them up > somewhere public. If that's the case, in all this time since 2.4 (when we > had the last refresh of Mike's dependencies package), then I wonder if we'll > be able to find someone willing to volunteer the time to do it officially. This is reflection of our over dependence on the time and skills of too small a group of engineers (i.,e Mike) , and lack of a process for getting binaries made available in straight forward way. Automating the process of creating dependency packages or more to the point de-skilling the process would make it possible for more users to get involved. Automating the dependency build isn't trivial though... > That's one place where the Linux package management systems are a real boon, > they totally remove this issue - you can just build an OSG package that > depends on a given version of libjpeg-dev, freetype-dev, etc. and you're > done, the package system will pull down the right version of the dependency > automatically. I really wish there was something like that on Windows, at > least for open source applications/libraries. That and a system-default > place to install libraries like on Linux too... Could we come up with a scheme that mirrors these packaging systems a little? I don't mean a full blown implementation of packaging system. Would it be possible to write a Cmake or Python script that manages a directory tree of dependencies? On the the dependency from I do wonder if providing CMakeLists.txt files for the various dependencies and then a high level CMakeLists.txt or other script that would pull together the components. Would we need to branch the source codes of the various dependences for this? Could we push support for such a coordinate build scheme back upstream to the projects themselves? > Then there's the issue of installers. I'm not sure an installer is the best > way to package OSG for Windows. OSG itself is not an application, it's a set > of developer libraries and example programs. I think making an installer > would make people think that the examples can be run with a double-click, > which in most cases is not true (most of the examples require command line > arguments to run). > > I think a zip containing binaries and headers (what's needed to build a > project linking to OSG) would be good enough. Sure, some libraries use > installers (Wx, Qt come to mind) but I think it adds extra complexity and > goes into parts of the system (the registry) which are not necessary. Plus, > since there's no easy way to update software that's installed with > installers (unistall + reinstall is the norm), just unzipping the new > version is quicker and less error-prone. I'm happy to start simple and work our way up if required. Perhaps in a final installer nirvana we could have an cross platform interactive script (in a browser maybe) that could run, you tick the bits of the OSG you want have it go install all the binaries/headers/source you need, or update any components when updates are available... ;-) What are the first steps on this road though... Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
