"There is a redundant cmake code at the end of osgViewer cmake script. The install command is issued in SETUP_LIBRARY macro."
"I spotted this when i tried a make install on the android port :) I saw some weird copy commands of osgViewer headers.
I managed to get all osg headers copied to cmake_install_prefix/include upon make install, but i can't (yet) get the libraries to be copied to cmake_install_prefix/lib (see attached files)"
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."
SETUP_EXE, in order to have a unique entry point to build the
libraries. With this changes the android integration will be less
painful (currently is a big IF(ANDROID) for each CMakeLists.txt) and
more maintainable in the future. I hope next submissions will be for
supporting android from my colleague Jorge.
"
I have attached a patch, against the trunk from 13:30 today, which consists of the following:
1. CMakeModules/FindOpenEXR.cmake: Look for libIlmThread and libIex as well. 2. src/osgPlugins/CMakeList.txt: Only include the exr subdirectory if both the OpenEXR and zip libraries were found. 3. src/osgPlugins/exr/CMakeLists.txt: Add ZIP_LIBRARY to TARGET_EXTERNAL_LIBRARIES."
I modified the OsgCPackConfig.cmake.in and OsgCPack.cmake files to expose access to select the package generator mechanism through cmake CPACK_GENERATOR option. The user can specify the type of package generator (i.e. rpms. deb, NSIS, tar, zip, etc) that they would like to use from the CPack supported packages/installation methods.
I also changed the CPACK_PACKAGE_FILE_NAME to use OSG_PACKAGE_FILE_NAME which contains the name of each component so all of the component packages can be generated without renaming the files.
This should make it even easier to create distribution packages for the various linux, windows and mac distribution methods supported by CPack."
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.
"
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.
"changed the CmakeFiles for OpenThreads and the
osg-frameworks, so they are versioned by OPENSCENEGRAPH_SOVERSION. "
And from a later email:
"Attached you'll find a fixed version of ModulInstall.cmake. Hopefully it
works for old CMake-versions. I removed the offending line, and the
compile went fine on my end."
I added support to find libxml2 in the 3rdparty package if available.
Now this file can find all libraries from the 32/64bit VS2008sp1 dependency package except collada. I will add that later.
"
I don't understand the changes to ReaderWriterFBX.cpp - (i) strings.h isn't a standard header, (ii) the ISO-conformant form is _strnicmp (with the underscore). Does the existing code not compile for you? If not we'll have to do some #ifdef nastiness."
latest OSG source code with Visual Studio 2010 express, without
setting too many options and without facing unexpected errors. But at
present, the compilation process will fail because the INSTALL project
'cannot find' generated DLLs while copying files. I have looked into
the build directory and found that the places of generated file
folders were just different from previous VS versions. In this case,
the old hack in OsgMacroUtils.cmake may become invalid:
MACRO(HANDLE_MSVC_DLL)
#this is a hack... the build place is set to lib/<debug or
release> by LIBARARY_OUTPUT_PATH equal to OUTPUT_LIBDIR
#the .lib will be crated in ../ so going straight in lib by
the IMPORT_PREFIX property
#because we want dll placed in OUTPUT_BINDIR ie the bin folder
sibling of lib, we can use ../../bin to go there,
...
ELSE(NOT MSVC_IDE)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX
"../../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
ENDIF(NOT MSVC_IDE)
ENDMACRO(HANDLE_MSVC_DLL)
Here the prefix "../../bin" may need to be fixed. I just modified it to:
IF(MSVC_VERSION LESS 1600)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX
"../../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
ENDIF()
It should keep compatible with old MSVC versions. There are similar
fixes in the SETUP_PLUGIN and SETUP_EXE macros. I haven't tested them
on more platforms.
"
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."
Windows. If the 3rdparty directory isn't available it will use the
directory names subversion uses such as 3rdParty_win32binaries_vs71
3rdParty_win32binaries_vs80sp1 3rdParty_win32binaries_vs90sp1. That
helps when as we are building both vs71 and vs80, and probably vs90 in
the future at the same time in addition to not having to rename the
directory once it is downloaded. It also adds the _i suffix to match
some of the libraries.
"
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."
- OsgMacroUtils.cmake, SETUP_LINK_LIBRARIES macro : allow linking with debug/release external libraries
- osgQt/CMakeLists.txt : fix the linking to Qt librairies + linking to debug Qt librairies if found
- examples/ qt examples : linking to debug Qt librairies if found"
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.
"
The collada dom Makefiles actually build a framework called Collada14Dom.framework (debug: Collada14Dom-d.framework). The current CMake rules, however, only look for collada14dom. Normally, the difference in case wouldn't matter but the rule fails on case sensitive HPFS partitions.
"
FREETYPE_INCLUDE_DIR_freetype2.
The error case was that during first cmake run (unspecified
ACTUAL_3RDPARTY_DIR) FindFreeType set these to xxx-NOTFOUND. After
specifying ACTUAL_3RDPARTY_DIR, Find3rdPartyDependencies warn't able
to change these (without FORCE).
I also added freetype237 to the library search list since it is what's
in my binary dependencies for vc90"
-I changed the SET of COLLADA_BOOST_INCLUDE_DIR to use findpath, so users may override this setting if they choose not to build against to precompiled boost libraries delivered with the Collada DOM.
-Changed daeRMaterials.cpp to prevent a compiler warning about a potentially uninitialized variable."
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"
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)"
Attached is a modified FindOpenEXR.cmake module that locates IlmIlf and Half, as well as a modified exr/CMakeLists.txt that picks up this change.
Also attached are some typo fixes for CMakeModules.
Cheers,"
Also, I've modified the FindCOLLADA.cmake to locate the current 2.1 versions of the COLLADA DOM in the build directories under VC8. I've also added a COLLADA_LIBRARY_DEBUG spec. Other flavors may be added depending on compiler version and DOM version."
"
and a later post the same osg-submissions thread:
"it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds."
And another post from Blasius on this topic:
"I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.
In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))
should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b))
The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I attached a corrected version.
Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere.
OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that.
"
MSVC_VERSIONED_DLL, NMake makefiles and CMake 2.6.2.
The compilation fails because it tries to copy ot11-OpenThreads.lib to
OpenThreads.lib which is valid for the 2.4.x era of CMake but not
anymore in 2.6.x era.
The provided file from the CMakeModules directory adds a tests on the
CMake version and corrects this. Works for me now."
CMakeLists.txt changes: "I installed latest Cmake(2.6.1) on a new machine and got a CMP008
warning from cmake. This fix set up osg to use the old behaviour which
have worked before. We might set this to NEW but I need to do more
testing first. I'l be able to test this on winxp with msvc80/90 and
ubuntu hardy with gcc-4.2.
quote from cmake cvs log
policy CMP0008 to decides how to treat full path libraries that do not
appear to be valid library file names. Such libraries worked by
accident in the VS IDE and Xcode generators with CMake 2.4 and below."
OsgMarcroUtils.cmake changes: "On Philips suggestion truncated a redundant if/else construction in
OsgMacroUtils to avoid developer warnings in cmake-2.6.1 concerning
cmake policy CMP0008 which allows full paths to libraries only with
valid library names
"
MemoryBarrier() is used in the implementation, so it should be checked.
This in effect disables the faster atomic ops on msvc 7.1 and older, even if
only the MemoryBarrier() call is missing. But it ensures for the fist cut
that it will build everywhere. If somebody cares for msvc 7.1 enough and has
one for testing installed, he might provide the apropriate defines to guard
that MemoryBarrier() call.
I tested that msvc8 32/64bit still passes the configure tests and compiles.
"
implementation of the atomic increment and decrement into a implementation
file.
This way inlining and compiler optimization can no longer happen for these
implementations, but it fixes compilation on win32 msvc targets. I expect
that this is still faster than with with mutexes.
Also the i386 gcc target gets atomic operations with this patch. By using an
implementation file we can guarantee that we have the right compiler flags
available."
atomic related compile failures with msvs2005. Attached changes to make win32
really use the atomic stuff. There are pointer typecast problems and some
historic alignment restrictions that I just took from a previous similar
implementation of mine without looking deep enough. "
