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.
1. Install the .pc file for osgIntrospection only if it is compiled,
instead of unconditionally.
2. New .pc file for osgQt, also created only if that library is actually
compiled.
"
Mathieu Marache, he added the last missing piece to this puzzle.
I think it is safe to commit these changes to trunk, as the traditional
way via dylibs should work as before.
Here's some more info how to get frameworks:
With these modifications it is possible to compile frameworks on OS X,
when you set the Cmake-option OSG_COMPILE_FRAMEWORKS to true. If you
want to embed the frameworks in your app-bundle make sure to set
OSG_COMPILE_FRAMEWORKS_INSTALL_NAME_DIR accordingly.
You'll have to build the install-target of the generated xcode-projects
as this sets the install_name_dirs of the frameworks and plugins."
currently only Debug appends "d" so the Release and MinSizeWithDebInfo
(and MinSizeRel) all produce the same filenames. This set of changes
lets each build type have a cmake defined string appended, defaulting
to Release none, Debug d, RelWithDebInfo rd, MinSizeRel s. But a user
still can have Release, RelWithDebInfo, and MinSizeRel to produce the
same filenames. It does so by setting the preprocessor define
OSG_LIBRARY_POSTFIX in src/osgDB/CMakeLists.txt to one of the
previously defined cmake variables CMAKE_DEBUG_POSTFIX
CMAKE_RELEASE_POSTFIX CMAKE_RELWITHDEBINFO_POSTFIX
CMAKE_MINSIZEREL_POSTFIX. This method cuts down on the #ifdef _DEBUG
#else preprocessor directives in Registry.cpp as the extension is
always passed in OSG_LIBRARY_POSTFIX. That and __MINGW32__ didn't
have the _DEBUG check which looks like a bug."
Introduced the OSG_NOTIFY_DISABLE Cmake variable + include/osg/Config #define to control whether the OpenSceneGraph build
should disable the notification system completely. By setting OSG_NOTIFY_DISABLE to ON in CMake and then rebuilding the
the OSG you can get a slightly smaller (~1%) and more slightly efficient library which can be good for shipping applications,
but with downside of reduced ability to detect runtime problems and their causes.
almost all Linux distributions. Although it is 100% compatible with ld,
by default it gives an error if a library has unresolved symbols at link
time, that is, it has set -Wl,--no-undefined by default. Debian folks
have found that libosg.so and libosgDB.so use some functions belonging
to libdl.so {dlsym,dlopen,dlclose,dlerror} without linking to it.
My changes link those two libraries to libdl.so explicitly in the same
way it is already done for libm.so and librt.so."
synchronization, improve capture device support.
here how to use it to display a capture device:
osg::Options* options = new osg::Options;
options->setPluginStringData("captureWantedWidth", "800");
options->setPluginStringData("captureWantedHeight", "600");
options->setPluginStringData("captureWantedFps", "30");
options->setPluginStringData("captureVideoDevice", "USB Video Device" );
options->setPluginStringData("captureSoundDevice", "");
then
osgDB::readImageFile("capture.directshow", options)
you can use a graphedit application to list devices available in
directshow.
for classic avi file you just need to do a
osgDB::readImageFile("file.avi.directshow");
You will need of course to install the codec needed by directshow to
read the avi files.
I recommand this tool http://avicodec.duby.info/, that check which
video/sound codec is needed to play an avi file.
You can test it with the osgmovie example.
"
settimeofday), OSG animations will freeze your application because
osg::Timer uses gettimeofday internally on non-Win32 platforms. This
is wrong and should be replace with times(2) or clock_gettime(2).
The attached patch fixes the issue in a binary-compatible way by using
clock_gettime when it's available, and falling back to gettimeofday
when it's not."
Most notable the __hpux define stuff. The __hpux__ variant seems to be not
defined which resulted in a compile error at this time. Consequently I have
replaced all occurances of __hpux__ with __hpux. And huge surprise: now osg
plugins are found and loaded correctly ...
The next notable one is the MSVC_IDE fix which makes the nmake Makefiles cmake
generator target behave like the ide one. Showed up because I started to do
scripted builds with nmake instead of devenv...
The rest is the usual bunch of stuff that just happens during normal
coding ..."
Introduced a new callback osgDB::FindFileCallback that overrides the default behavior of findDataFile/findLibraryFile.
Introduced support for assigning ReaderWriter::Options directory to PagedLOD.
Introduced new osgDB::FileLocationCallback for assistancing the DatabasePager to know when a file is hosted on a local or remote file system.
Converted Present3D across from using libxml2 to using the new osgDB::XmlNode/XmlNode::Input classes from Xml Parsing.
This changes removes the dependency on libxml2, and allows the present3D application and p3d to work on all platforms.
http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/42400
Since this is a workaround for a bug in a beta OS (which may or may not be fixed, since it's mentioned in their release notes so they may just leave it as it is) I've marked the option as advanced, default to OFF, and clearly documented it as being useful for Windows 7 only. I'd like to be able to test for Windows 7 directly instead of the blanket IF(WIN32), but I can't figure out if this is possible in CMake.
Here's the modified CMakeLists.txt. It's a small change, with low impact, but will be useful to others who test out this OS and when it comes out. Note that I'm not familiar with this option in general, and didn't get any feedback to my questions in the above-mentioned thread, one of which was: Could we just add this option to all builds? What is the impact? That's still unclear to me, but without it OSG executables don't build, and the article I linked didn't seem to present any ill effects to enabling the option."
1. Makes IF/ELSE/ENDIF code blocks easier to read by replacing code like this:
IF(FOO)
MESSAGE("FOO is true")
ELSE(FOO)
MESSAGE(" ??? ELSE(FOO)??? ")
ENDIF(FOO)
with this:
IF(FOO)
MESSAGE("FOO is true")
ELSE()
MESSAGE("FOO is clearly false")
ENDIF()
2. Also adds an ELSEIF() where it makes sense to do so (safe to use as of CMake 2.4.4)"
talking about in the LIB_POSTFIX thread. It is a bit verbose perhaps
and the message I emit during the make install step flashes by and
gets burried under all "installing..." and/or "up-to-date..."
messages. I have posted on the cmake mail list on ways to do this
better.
The submission adds:
* message to user during configuration that s/he's eventually going o
install to ${CMAKE_INSTALL_PREFIX}lib${LIB_POSTFIX}
* if system has /etc/ld.so.conf.d and it is a dir generates
packaging/ld.so.conf.d/openscenegraph.conf and creates a custom target
for installing it (target must be run explicitly of course). User is
notified of this during configuration (may not be necessary)
* emit a message during installation that libraries are put in
<same-as-above>. This message unfortunately gets emitted to soon for
the user to see it
* I added "COMPONENT libopenscenegraph-dev" to the pkgconfig.pc's
install command
* Moved the section with OSG_CONFIG_HAS_BEEN_RUN_BEFORE as close to
the end of CMakeLists.txt as I dared. This is the intent of this
construct I think."
openscenegraph.pc and openthreads.pc files with OSG's installation values.
Then I install those files into the expected path for pkg-config (this can
also be modified through PKG_CONFIG_PATH environment variable). Therefore
those of us who are using pkg-config for linking can easily select which
version of OSG we want to use."
name of the top folder in each package to OpenSceneGraph-x.y.z
Noone else has had an opinion on whether compiler and it's version
should be part of the package filename on their platform/setup so I'll
leave it as is. That is - No action is taken for compilers other than
msvc but one can easily add this information to the cmake cache
regardless of platform.
"
streamlined for tgz and has most of the features that Robert, J-S and
Sukender requested in december. I have an idea of how to discover the
vc80 sp1 or not but haven't had time to implement. The script is
completely reworked and now doesn't include cmakes' bundled
CPack.cmake script at all. In summary:
* filenames are
<package>-<osgversion>-<platform>-<arch>[-compiler]-<configuration>.tar.gz,
ex. libopenscenegraph-2.7.9-Linux-i386-Release.tar.gz,
libopenthreads-dev-2.7.9-win32-x86-vc80sp1-Debug.tar.gz
* targets (projects in msvs) are generated for each specified
component, a target that packages everything that is installed
(openscenegraph-all) and there's a target for running all other
packaging targets (Package ALL on msvs, package_ALL in unix
makefiles).
* It is possible to set the compiler in ccmake (cmake-gui, whatever you use)
* the top folder in packages is the same for all packages (OpenSceneGraph-x.y)
* the packaging support is limited with cmake-2.6.0 and not as
dynamic. With cmake-2.6.1 and later building the gdal plugin (for
example) will create a package_libopenscenegraph-gdal target. With
cmake-2.6.0 only the ones that are always built (libopenscenegraph,
libopenscenegraph-dev, openscenegraph, libopenthreads,
libopenthreads-dev
* i found a better way to decide whether cpack is available to guard
the BUiLD_OSG_PACKAGES option"
of cmake-2.6.0. As a side note I just installed cmake from the ubuntu
repositories and got cmake-2.6.0-4ubuntu2 and this one produced the
currect CMAKE_CXX_FLAGS_RELEASE (-O3 -DNDEBUG). This CMakeLists is
tested on linux with cmake versions 2.4.8, 2.6.0, 2.6.2 and
2.6.0-4ubuntu2
* Added quotes around CMAKE_CXX_FLAGS var to help cmake-2.6.0 pick up
that it really is a string value
* Removed quotes around values that we set in
OSG_AGGRESIVE_WARNING_FLAGS. This makes OSG_AGGRESIVE_WARING_FLAGS be
of LIST type so the foreach constructs can behave as I planned."
that set aggressive warnings in CMAKE_CXX_FLAGS and the on that
processes the source tree(s) or the newly set flags wouldn't take
effect until second consecutive configure.
I also replaced the internally cached variables that managed the
aggresive warnings with explicit adding and removing of flags in
CXX_FLAGS
For apple we first required min cmake version 2.6.0 and then had code
warning about using 2.4.x"
* Removed processing of include/OpenThreads in the OpenSceneGraph refman
* Clears the mark_as_advanced property of the BUILD_DOCUMENTATION
cmake variable (so it gets visible in simple view).
"
Updated all doxyfiles under doc/Doxyfiles. They are now all processed
by cmake but make targets are only generated for
OpenSceneGraphReferenceDocs and OpenThreadsReferenceDocs. The others
can be run with doxygen directly in <builddir>/doc.
Fixed a copy-paste in openthreads sproc and pthreads CMakeLists
Added the osg logo to the html footers
Added possibility to get generation of chm files.
CMakeLists (toplevel):
Added install of osg and ot reference docs. This also generates
packaging targets of openscenegraph-doc and openthreads-doc if you
have packaging enabled
Removed the unused USING_OP_OT_TRIPLE_SET since there was no way of
enabling it anyway
Removed BUILD_REF_DOCS. IMO it was redundant - BUILD_DOCUMENTATION
does the same thing and we get that anyway from including
Documentation.cmake.
OsgCPack.cmake:
Removed generation of PACKAGE_SRC for msvc
Added special handling for -doc packaging targets - they don't require
system, architecture or compiler"
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"
consider these initial cpack support scripts. It is hidden behind a
BUILD_PACKAGES option so won't affect the normal user. The submission
1) set the COMPONENT attribute on all cmake install commands.
COMPONENT names are according to
http://www.openscenegraph.org/projects/osg/wiki/Community/Packaging
2) provide cmake script and a template for creating CPack
configuration files. It will generate target for creating packages
with everything that gets "installed" (make package on unx, project
PACKAGE in MSVC) plus targets for generating one package per COMPONENT
(i.e. libopenscenegraph-core etc.).
I have temporariliy uploaded some examples to
http://www.openscenegraph.org/projects/osg/wiki/Community/People/MattiasHelsing
If this submission makes it into svn we can develop it to generate
rpms, installers for windows and mac (I know at least J-S don't like
these but there may be others who do ;) and even DEBs (not sure if we
can make them "ubuntu-ready" but they eventually may - at least we
could put a deb on the website)"
I have not reverted added Compiler options. I assume that one may want to have warnings enabled for the application but may not want to see them while OSG libraries and examples compile.
Modified files:
osg/Export - now explicitly includes osg/Config to make sure OSG_DISABLE_MSVC_WARNINGS is read
osg/Config.in - declares OSG_DISABLE_MSVC_WARNINGS flag to be added to autogenerated osg/Config
CMakeLists.txt - declares OSG_DISABLE_MSVC_WARNINGS as option with default ON setting
"
I suggest moving the definition of OSG_DEFAULT_LIBRARY_PATH (which is responsible for this global rebuild) into osgDB/CMakeLists.txt which is the only library in the code where this definition is (and is likely ever to be) used. This way if the user changes it, only osgDB will rebuild."
set to off. But could be activated/decativated via CMake as well as system
environment variable. I also modified src\osgViewer\CMakeLists.txt to turn
off this workaround by default as suggested."
