Hi Robert,
One couldn't have a totally open system for uploading. Only
maintainers would be able to upload. We could include a number of
maintainers for each platform. Testing would need to happen of
course, and perhaps a holding area for proposed packages would suit
this phase. Once a package is tested and approved only then would
link to it from the download pages/move it to general public downloads
area.
I agree, that sounds like a good way to manage that. It all hinges on
getting maintainers to sign up though.
Could we just provide our own external CMake system for them then?
Most of these dependencies are complex beasts.
Yeah, I think that would be unweildly. But I won't know until I try it.
For the most part I would expect dependencies would change rarely.
Certainly less often than OSG releases.
Of course. And we will *need* to bump a dependency's version even less
often (we don't need to always be up to date, just use the version
that's stable and has the features we need).
So what options do we have for streamlining the build of the dependencies?
That's what I'm not sure about.
One option would be scripting, as you said. A Visual Studio project can
be built from the command line (through arguments to devenv.exe), so it
can be scripted. The same goes without saying for nmake-based builds.
Mike's way of working is not bad I think. He has a script that fetches
the upstream sources (a specific version, which can be controlled in
another script), unzips them to a directory, and then either builds it
or gives instructions on which project to open up and what to do to
build it. He also commits to his repo any changed project files, so that
the sources are not forked but there is a trace of what he needed to change.
So just modifying that methodology to build Visual Studio projects from
the command line too, and then automating the packaging (just zipping up
the necessary build products and headers) would be a good place to start
I think.
The part that's tedious is changing project settings and build options
to be able to build debug and release side by side, and so they use the
same VC runtime, etc. But as you said, we shouldn't have to update
dependencies too often, so it might not be so bad. If the rest is
automated, it'll be OK I think.
I'd be inclined towards static linking of these libs too, the only
other alternative is for use to name/version our built dependencies
uniquely so as not to risk overlapping with other installs of similar
but not quite the same libs.
Agreed.
There are also other heavier weight dependencies like COLLADA,
OpenVRML, LibXUL/xulrunner that users might want to pull in. The
existing Win32 dependency list is really just the core dependencies.
How far out one should encompass centrally will something we should
leave the community - if volunteers are willing to support a
particular dependency package and there is a mechanism for us to
provide download space and consistent scheme for naming then we can
just leave the door open to this more specialist add ons.
Agreed.
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
