Introduced new scheme for setting up which version of OpenGL/OpenGL ES the OSG is compiled for.

To select standard OpenGL 1/2 build with full backwards and forwards comtability use:

  ./configure
  make

OR

  ./configure -DOPENGL_PROFILE=GL2

To select OpenGL 3 core profile build using GL3/gl3.h header:

  ./configure -DOPENGL_PROFILE=GL3

To select OpenGL Arb core profile build using GL/glcorearb.h header:

  ./configure -DOPENGL_PROFILE=GLCORE

To select OpenGL ES 1.1 profile use:

  ./configure -DOPENGL_PROFILE=GLES1

To select OpenGL ES 2 profile use:

  ./configure -DOPENGL_PROFILE=GLES2


Using OPENGL_PROFILE will select all the appropriate features required so no other settings in cmake will need to be adjusted.
The new configuration options are stored in the include/osg/OpenGL header that deprecates the old include/osg/GL header.
Added src/osg/OpenGL.in configuration file and include/osg/OpenGL header files
Removed header as this CMake generated configuration file is not required to be part of svn repository
Fixed typo in OPENSCENEGRAPH_OPENGL_HEADER name
Fixed reference invalidation bug.
From Mattias Helsing, "Seems I was only half right given what you asked for. CMP0017 only
says that modules that are found and ran from cmake modules dir should
prefer cmake-provided modules. find_package() and include() still look
in CMAKE_MODULE_PATH first.

After some investigating I've come up with a proposal examplified in
the attached FindGDAL.cmake script. It simply calls the cmake provided
FindGDAL.cmake if it exists and returns if it succeeds in finding GDAL
using that, otherwise continue with our local cmake code.
Pro: Wont clutter our root CMakeLists.txt
Con: If we begin to write more advanced Findxxx modules (using
COMPONENTS, REQUIRED etc.) we may have to revise this scheme.
"
From Kristofer Tingdahl, "I and my team have gone over the code again, and we feel that we are comfortable in our current proposal for change. It goes deeper than it did before, and I explain why:

There was code in the osgViewer/Viewer.cpp and osgViewer/CompositeViewer.cpp that transformed the Y-coordinates of an event. The code in the composite viewer did however miss the touch-data of the event. I thought that it should really be the GUIEventAdapter that should know about this, and hence I added the
GUIEventAdapter::setMouseYOrientationAndUpdateCoords which is re-computing the coordinates. First I simply added a boolean to the setMouseYOrientation function:

setMouseYOrientation( MouseYOrientation, bool updatecooreds=false );

but then the serializer complained.

This function is called from both the Viewer and the CompositeViewer. We have not tested from the viewer, but I cannot see it would not work from visual inspection.

The other change is in MultiTouchTrackballManipulator::handleMultiTouchDrag. I have removed the normalisation. The reason for that is that it normalised into screen coordinates from 0,0 to 1,1. The problem with that is that if you have a pinch event and you keep the distance say 300 pixels between your fingers, these 300 pixels represent 0.20 of the screen in the horizontal domain, but 0.3 of the screen in the vertical domain. A rotation of the pinch-fingers will hence result in a zoom in, as the normalised distance is changing between them.

A consequence of this is that I have changed the pan-code to use the same algorithm as the middle-mouse-pan.

The rest of it is very similar from previous revision, and there has been some fine-tuning here and there.

"
From Lionel Lagarde, "In the ::apply method, when the image data need to be re-uploaded, the Texture2DArray checks if the TextureObject can be re-used. The test was made using the constant 1 instead of the real texture depth, so the TextureObject was never re-used."
From Farshid Lashkari, "I've attached a small fix to the Collada loader which prevents a null pointer access in some cases."
From Paul Martz, fixed placement of OpenGL header so that it gets generated and placed in the build directory as per the Config file
Reordered the configuiration file blocks to make it more understandable
From Pjotr Svetachov, "For me osgviewer.cpp and Renderer.cpp were not compiling (visual studio 2013 with profile GL2) because they were still using GLuintEXT. So I changed that, see the attached files.

I also noticed that the generated OpenGL header were not copied to the installation directory so my own application could not find it."
Fixed type error
From Jason Beverage, "Here is a fix for a small race condition in osgDB::makeDirectory.  It attempts to create all the directories in the given path and stops attempting to make directories when one of them fails.  I've added a check to see if the failure occurred b/c the directory was created by another thread or process.

We were running into issues occasionally in osgEarth where multiple threads were writing out files like /1/2/3.jpg and /1/3/4.jpg.  Both threads would try to create the /1 directory and only one of them would succeed.  So the first thread would write out the full /1/2/3.jpg while the second thread wouldn't create the /1/3 directory b/c /1 was already created and the writing of /1/3/4.jpg would fail.
"
From Pjotr Svetachov, "I had the osgvolume example crash on me when loading large volume
datasets due to an overflow in image.cpp after a unneeded cast from
unsigned int to int. Here is a small fix."
From Paul Martz, "There is no standard place for gl/glcorearb.h on Windows. Previously, the only way to get OSG to build for core profile was to append an additional include directory ("/I") onto the CFLAGS variables This submission adds a FindGLCORE.cmake script so that the path to gl/glcorearb.h can be specified with a variable, GLCORE_ROOT, either in CMake or the environment.

Currently this submission is Windows-only. I don't think OSX or Linux require any help in locating gl/glcorearb.h. But if they do, this submission can be easily modified.

Files:
 - "CMakeLists.txt" is the top-level file.
 - FindGLCORE.cmake" and "OsgMacroUtils.cmake" go in CMakeModules.
"
From Mattias Helsing, "I finally got to fix the cmake Modules that have duplicates in later
version of cmake. See attached submission. I have tested the ones that
I compile myself (GDAL, Freetype, ZLIB) on ubuntu 12.04 with
cmake-2.8.7."
From Pjotr Svetachov, "Today I found a bug in the IutputStream class when saving array
attributes in vec3b format. It looks like my compiler takes the wrong
overload and outputs integers instead of characters. The problem is
that vec3b is of type signed char and that is not the same as char (
see http://stackoverflow.com/questions/436513/char-signed-char-char-unsigned-char
) and visual studio 2013 will promote it to integer when choosing an
overload.
It looks like that the InputStream class already takes care of this
issue (if it didn't it would have read everything ok and I would have
not even stumbled upon this bug. :) )"
From Pjotr Svetachov, "have added some missing serializers for RigGeomery. Withouth them I
ran into two issues.

At first you get a bunch of warnings that osg::ComputeBoundCallback
and osg::UpdateCallback were unsupported wrapper classes when
converting fbx models with skeletal animation to osg(t/b).

The second issue was that when reading, the readers fail to read the
ComputeBoundCallback and UpdateCallback and set them to NULL which
messes up the RigGeometry.

Because a RigGeometry makes his own classes in the constructor it
might be preferable to not write them at all, because now those
classes are being made two times when reading a RigGeometry. But after
thinking about this that would place too much limits on them (you
won't be able to share or name them and save that information or make
a new inherited class from them and write that one) So I ended up
thinking the best way was to just write the files.
"
From Sebastian Messerschmidt, "attached is the compile/linker fix for multiple definitions of getTypeEnum when compiling the Lua with VisualStudio and potentially other compilers.
"