Hi Robert,
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.
Some open repository would be useful, sure, but it would increase the
need for testing, since anyone could replace a given working revision of
the binaries with a non-working one, someone would need to constantly
monitor what's going on on the repository and test the changes...
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.
Yep.
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...
...
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?
I doubt the upstream maintainers would be willing to maintain files for
a build system they don't use. None of the 7 dependencies I built
recently for our own internal packages use CMake. Each one has their own
build system, which is what makes it a pain. Some build using Visual
Studio, some using nmake.
When you need to change settings, you either have to dig in the VS
project files, or the makefiles, and the makefiles are always set up
differently, so it takes a lot of time. Adding the "d" postfix for debug
libraries is an example. I doubt the projects themselves will be open to
changes to their build system, that's generally a preference of the
build maintainers, so these changes will need to be re-done each time we
bump the version of one of the dependencies.
All in all, I'm already doing it once every 4-6 months for work, I
personally don't want to do it any more than that. Mike seems to have a
similar stance. If someone wants to do it feel free.
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?
Perhaps. Or we could compile apt for Windows :-)
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...
Not sure.
I really think the dependencies are the biggest hurdle. If someone can
streamline the dependencies build process, then at least we would have
dependencies for the 3 major toolsets (VC7.1, VC8, VC9). Building OSG
with those is a piece of cake... Even if we have to do it 6 times (3
toolsets * (debug + release)).
The basic dependencies included in Mike's repo (and I think we should
start with that basic set too) are:
1. curl (not necessary but will be useful in the future)
2. freetype
3. libjpeg
4. libungif
5. libpng
6. libtiff
7. zlib (included with libpng)
Choosing which to build as static libs and which as dynamic libs is a
first decision to take. I would personally go static all the way because
there are more and more applications that add themselves to your PATH on
install and include for example libpng, so your OSG app ends up picking
up the wrong DLL and crashing. But it does increase the plugins' size a bit.
I didn't want to, but I could volunteer to build the dependencies for
the next release. Given a few weeks to do it in my off time, I would be
able to do it. From that, I would have a better idea of what can / needs
to be streamlined and I could suggest some next steps.
Comments?
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
