IF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.7.sdk")
...
ELSEIF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.5.sdk" OR ${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.6.sdk")
...
ELSEIF(EXISTS /Developer/SDKs/MacOSX10.4u.sdk)
...
ELSE()
...
ENDIF()
Which is fragile because XCode could be installed into another directory than /Developer. (In case XCode is not installed into the /Developer directory CMake can automatically resolve the path via command line utility ${CMAKE_XCODE_SELECT} --print-path)
This issue bites me currently because the latest XCode (Version 4.3.1 - 4E1019) installed through the Mac App Store is per default installed in "/Applications/Xcode.app/Contents/Developer" and hence the 10.7 SDK in "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
Searching the web to find the proper way to determine the version of the Platform SDK programmatically, I found no standard way. I came up with 2 options myself:
1) Parse the path string to extract the version number
2) Read a value from the SDKSettings.plist found in the root of each SDK (e.g., "defaults read ${CMAKE_OSX_ROOT}/SDKSettings.plist CanonicalName" gives "macosx10.7")
I implemented the last option and verified that at least the following Mac OS SDKs (10.3.9, 10.4, 10.5, 10.6, 10.7) support this method. It also looks reasonably future proof. An additional benefit of this method is that it also seems to be compatible with iOS and iOS Simulator SDKs (at least for version 5.1, but I assume this also applies to older versions). This is interesting because the CMake infrastructure to build OSG for iOS currently still contains similar hard-coded paths and even requires you to manually change the cmake file to build for another iOS SDK version. In the near future I hope to address these issues, but I haven't been able to try this yet."
I added AFAIK proper defaults for several Macos X Version API targets.
* In order to determine which defaults to apply, consult the CMAKE_OSX_SYSROOT variable pointing to the used SDK, not the pure existence of an SDK.
* Defaults are now:
10.7: Support Intel 32 and 64 Bit Cocoa with imageio picture reader
10.6 + 10.5: Support Cocoa with imageio on Intel and PowerPC
10.4: Carbon, Quicktime and PowerPC
Now OSG compiles out of the box for MacOSX 10.7. , tested with gcc and clang with FlightGear."
(http://gta.nongnu.org). This allows to read and write floating point
image data. Unlike other formats, GTA also allows very good compression
ratios for floating point data. The compression method can be selected
with the COMPRESSION option of the plugin.
"
2nd - Script to use a 3rd party directory with basic libraries: libjpeg,libpng,libtiff,giflib,freetype,curl,gdal.
3rd - Change in the GLES library loading for Android. That should make GLES2 work properly.
4rth- Included two defines RGB8_OES and RGBA8_OES as a substitute in GLES for RGB8 and RGBA8
5th - OpenGL and GLSL version identification changed to recognize GLES versions properly
"
I also modified the CMake and pkgconfig files to append the _POSTFIX extenstion based on the CMAKE_BUILD_TYPE.
Additionally I fixed packaging/ld.so.conf.d/openscenegraph.conf.in to add a '/' betweeen the arguments since the CMAKE_INSTALL_PREFIX can't end with a '/'.
"
This feature has been introduced to cmake in 2.8.3, on older versions it should be ignored silently. I tested on Visual Studio 2008 with cmake 2.8.3 and 2.8.4.
See the screenshots for comparison [img]osg_solution.png[/img]
This needs few changes:
activate on global cmakelist.txt:
[code]set_property(GLOBAL PROPERTY USE_FOLDERS On)[/code]
set appropriate folder names for project type in osgMacroUtils.cmake:
[code]SET_TARGET_PROPERTIES(${CORELIB_NAME} PROPERTIES FOLDER "OSG Core")[/code]
similar for examples, applications"
"- In order to build against GLES1 we execute:
$ mkdir build_android_gles1
$ cd build_android_gles1
$ cmake .. -DOSG_BUILD_PLATFORM_ANDROID=ON -DDYNAMIC_OPENTHREADS=OFF
-DDYNAMIC_OPENSCENEGRAPH=OFF -DANDROID_NDK=<path_to_android_ndk>/
-DOSG_GLES1_AVAILABLE=ON -DOSG_GL1_AVAILABLE=OFF
-DOSG_GL2_AVAILABLE=OFF -DOSG_GL_DISPLAYLISTS_AVAILABLE=OFF -DJ=2
-DOSG_CPP_EXCEPTIONS_AVAILABLE=OFF
$ make
If all is correct you will have and static OSG inside:
build_android_gles1/bin/ndk/local/armeabi.
- GLES2 is not tested/proved, but I think it could be possible build
it with the correct cmake flags.
- The flag -DJ=2 is used to pass to the ndk-build the number of
processors to speed up the building.
- make install is not yet supported."
changes from the DirectInput devices and add events to the event
queue. I've tested with the keyboard and joystick supports. Because of
only having a very old 6-button gamepad, I can't do more experiments.
Hope this will bring more ideas to those who face similar problems,
especially simulation game designers. :)
I didn't map all DirectInput key values to GUIEventAdapter key
symbols. Users may add more in the buildKeyMap() function freely. The
mouse handling operations are also ignored, but will be easily
improved in the same way of creating keyboard and joystick devices.
Please add a line:
FIND_PACKAGE(DirectInput)
in the CMakeLists of root directory. And in the examples/CMakeLists.txt:
IF(DIRECTINPUT_FOUND)
ADD_SUBDIRECTORY(osgdirectinput)
ENDIF(DIRECTINPUT_FOUND)
DirectX SDK 2009 is used here, but an older version like DX8 should
also work in my opinion.
"
- CMakeLists.txt
-- don't look for GL when compiling for iOS (device or simulator), look for OGLES instead
-- use architecture i386 for simulator
-- removed iphoneos-version-min for simulator
- examples/osgviewerIPhone/CMakeLists.txt
-- added build dependencies for osgdb_osg, osgdb_freetype, osgdb_imageio
-- added framework QuartzCore link dependency
- src/osgDB/CMakeLists.txt
-- don't link against Carbon on iOS (device or simulator)
- src/osgPlugins/freetype/CMakeLists.txt
-- don't link against OpenGL on iOS device or simulator
- src/osgViewer/CMakeLists.txt
-- link against OpenGLES on iOS (device or simulator)
- src/osgPlugins/imageio/CMakeLists.txt
-- compile ReaderWriterImageIO_IOS.cpp as Objective-C++
"
attached you'll find the second part of the IOS-submission. It contains
* GraphicsWindowIOS, which supports external and "retina" displays,
multisample-buffers (for IOS > 4.0) and multi-touch-events
* an ios-specific implementation of the imageio-plugin
* an iphone-viewer example
* cMake support for creating a xcode-project
* an updated ReadMe-file describing the necessary steps to get a
working xcode-project-file from CMake
Please credit Thomas Hogarth and Stephan Huber for these changes.
This brings the ios-support in line with the git-fork on github. It
needs some more testing and some more love, the cmake-process is still a
little complicated.
You'll need a special version of the freetype lib compiled for IOS,
there's one bundled in the OpenFrameworks-distribution, which can be used."
Notes, from Robert Osfield, modified CMakeLists.txt files so that the IOS specific paths are within IF(APPLE) blocks.
But I also found rev. 11354 (from Wang Rui) added a change in OsgMacroUtils which adresses a similar issue: Wang told the "../../bin" prefix wasn't working. However I think the fix isn't correct because it checks the MSVC version instead of the CMake version. Here is my fix, against latest trunk (root CMakeLists.txt, and CMakeModules/OsgMacroUtils.cmake).
Tests I made:
| Unix Makefiles | MSVC 9 | MSVC 10 x64
---------------------------------------------------
CMake 2.4 | | OK | N/A
CMake 2.6.4 | | OK | N/A
CMake 2.8.0 | | OK | broken support?
CMake 2.8.2 | | OK | OK
"
changed extensions from .c to .cpp and got compiling as C files as part of the osg core library.
Updated and cleaned up the rest of the OSG to use the new internal GLU.
