The changes are more or less just beautifications
(when looked at them from the C++ view), but make
wrapping OSG with SWIG easier.
I have tested the changes with both 2.8.1-rc4 and the
current head and would appreciate to incorporate the
changes in both branches.
Here is a description of the changes:
osg/BoundingSphere:
Use the following typedef (like used in BoundingBox)
typedef typename VT::value_type value_type;
instead of
typedef typename vec_type::value_type value_type;
SWIG reports errors on the latter construct.
Also makes it consistent with BoundingBox.
osg/Vec4ub:
Consistent use of "value_type" throughout the file.
osg/Vec?b:
Consistent use of "value_type" throughout the files.
Also changed
typedef char value_type;
to
typedef signed char value_type;
In the case of a simple "char", SWIG assumes a string.
Using "signed char" instead of "char" does not change
the behaviour of the class."
TimeLine : remove virtual inheritance that is not needed
RigGeometry : put some methods/members in private section (everything was public), use META_Object macro
osganimationskinning.cpp : remove two lines that are not needed"
Merged from svn/trunk:
svn merge -r 9736:9737 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk
to have an optional compile path for either using a OpenThreads::ReadWriteMutex or an
OpenThreads::Mutex as it's base implementation, with the Mutex now being used by default.
The fix was to convert the osg::State to use C pointers for the set of applied PerContexProgram objects, and use the osg::Oberver mechanism to avoid dangling pointers for being maintained in osg::State.
Better package naming. example
openscenegraph-core-2.7.7-Linux-i386.tar.gz on my ubuntu laptop and
openscenegraph-core.2.7.7-win32-x86-vc80.tar.gz on winxp.
CMakers will not get options for selecting compression format. TGZ
goes for all platforms (on win32 I use 7zip)
The wrappers is now given the COMPONENT name
libopenscenegraph-wrappers. Feel free to change the name.
On windows with visual studio the OsgCPack script make some efforts to
discover the compiler used but support is a bit poor so I've given
CMake acces to OSG_CPACK_COMPILER to provide some mean to name the
compiler.
stop
The platform part is taken from CMAKE_SYSTEM_NAME and for windows I
change this to win32 or win64 based on CMAKE_CL_64. This might not be
necessary if the arch part has that information. This information is
taken from CMAKE_SYSTEM_PROCESSOR. I only have 32bit here so if some
of you could uncomment line 15,16 in OsgCPack.cmake and report what
cmake report it would be nice. I'm especially interested anything but
win32 and linux32"
