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."