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
"
mode. Nevertheless, the code doesn't acknowledge that, so I had problems with
debug versions of the library not being able to open their plugins whereas
the release versions worked fine.
I have made the same changes in Registry.cpp that are available for the rest
of platforms appending that "d" to their plugins. I have also updated the
CMakeLists.txt file to get "_DEBUG" defined at compilation time. I have
copied the already existent conditional block because of cmake's bizarre
operator precedence. Since Cygwin defines both CYGWIN and WIN32, the
following would suffice:
IF(CYGWIN OR UNIX AND NOT WIN32 AND NOT APPLE)
Sadly, it actually doesn't work, so I wrote a new conditional block just for
Cygwin. I could join the two blocks when the parentheses support is added in
newer versions of cmake."
I needed a -DCMAKE_DEBUG_POSTFIX="d" not a -D"CMAKE_DEBUG_POSTFIX=d".
This corrects the build for the CMake 2.4 and 2.6 series
The error was in compiling osgDB/Registry.cpp
"
- Added osgviewerCocoa example to APPLE builds
- Fixed corrupt Xcode project generation with CMake 2.6 dealing with ADD_DEFINITIONS and CMake Policy CMP0005 on Leopard
- Resolved CMP0006 warning for examples and programs by setting BUNDLE DESTINATION to same as RUNTIME DESTINATION with CMake 2.6
- Fixed freetype plugin on Leopard to avoid OpenGL linking problem
- Figured out how to use a custom Info.plist included in the project (see osgviewerCocoa application CMakeLists.txt)"
first post:
"I had the problem that debug and release version of the plugins had the same name under linux. These minors modification to Registry and the CMake support files enable to have both Release and Debug version of the plugins to coexist and be found by there respective runtimes."
follow up post:
"I've gone ahead and added a preprocessor directive with the editable CMAKE_DEBUG_POSTFIX. I modified Registry.cpp to take this new preprocessor directive called OSG_DEBUG_POSTFIX while looking for libraries in Debug mode for the windows (msvc) and the linux platforms.
MinGW, cygwin and Apple are still left out this proposal."
Notes from Robert Osfield, completed the work in change d entries to use OSG_DEBUG_POSTFIX
The reason is if you want to build an application that use a library that use openscenegraph you have to build the full chain in debug or in release.
On windows you have no choice, but on linux you can link with both version without rebuilding everything ...
The patch consist only to change the line on one line
SET(CMAKE_DEBUG_POSTFIX "d")
with
SET(CMAKE_DEBUG_POSTFIX "d" CACHE STRING "add a postfix, usually d on windows")"
"Here is a collection of changes which should fix issues building the OSG with CMake 2.6.0 (along with some other changes)
CMakeLists.txt:
* Set CMP0003 to supress warning about linking against -lpthread (which is a
non-absolute library location). (CMake 2.6.x fix)
* Modified the WIN32_USE_MP and a couple of other Visual Studio specific flags
to be in an IF(MSVC) block (minor tweak to reduce exposing this stuff on MinGW builds)
* Includes my second set of glu tesselator autodetection changes that you
seemed to want but haven't committed yet.
src/OpenThreads/pthreads/CMakeLists.txt:
* Eliminates warning when compiling on Linux about spaces in link line (CMake 2.6.x fix)
CMakeModules/OsgMacroUtils.cmake:
* Tweaks to make the macros behave properly under CMake 2.6.0 (doesn't change behavior under CMake 2.4.x)
CMakeModules/Find3rdPartyDependencies.cmake:
* Adds the NO_DEFAULT_PATH option to all of the search options so that things in C:\Program Files\OpenSceneGraph aren't accidently picked up during configure time and instead only things in the "3rdParty" folder are discovered. (general bugfix)
"
post 2:
"Ok, hold the presses. I just discovered that for some odd reason the osgdb_* plugins under Linux aren't getting put under the osgPlugins-2.5.0 folder. Not exactly sure why this broke, the folder was there, just empty. I'll have to look into it this evening."
post 3:
"Fixed, was caused by the switch to CMAKE_LIBRARY_OUTPUT_DIRECTORY and some code in osgPlugins/CMakeLists.txt that effectively overrides LIBRARY_OUTPUT_PATH on non-MSVC compilers to dump the plugins in the plugins folder. I tweaked it to override CMAKE_LIBRARY_OUTPUT_DIRECTORY as well. Seems to work fine."
in Microsoft compilers as discussed in osg-users. There is now an
advanced option called WIN32_USE_MP (which defaults to OFF) that will
enable the /MP switch for all builds. I tucked this code block safely
within a IF(WIN32) branch."
Introduced code in BoundgingSphere, BoundingBox, ProxyNode and LOD to utilise the above settings.
Added Matrix::value_type, Plane::value_type, BoundingSphere::value_type and BoundingBox::value_type command line
options that report where the types of floats or doubles.
This is caused by the OSG_MSVC_VERSIONED_DLL hack.
there are hard-coded paths to place the dll's in the bin /dir that normally would go
in the lib/config (release/debug) dirs. Nmake has different locations for the files (no config dir).
fix: change the macro's in OsgMacroUtils.cmake for the IF(NOT MSVC_IDE) situation.
Libs go in lib/, and DLLs and executables go in bin/
To accopmplish this for MSVC_IDE the targets get a "../../bin" prefix,
for nmake this should be "../bin" (because there are no config folders).
This fix mimics the behaviour of the MSCV_IDE (visual studio) build system when building with nmake.
Note:
A change in the main CMakeLists.txt creates the needed plugin directory in the binary dir.
see included files for the changes:
r7885fix-v2/CMakeModules/OsgMacroUtils.cmake
r7885fix-v2/osgWrappers/CMakeLists.txt
r7885fix-v2/CMakeLists.txt
The behaviour of visual studio projects (and other build systems) remain unchanged.
Tested building and installing with nmake and visual studio 8 debug and release.
"
CMake build system, enabling this option will build the OSG against the (...) version
of the tesselation callback functions.
One can also set the default value of this option via the DEFAULT_GLU_TESS_CALLBACK_TRIPLEDOT
variable that is set locally to OFF for all platforms except AIX and OSX, but can
be overriden by setting it via command line option i.e.
cmake . -DDDEFAULT_GLU_TESS_CALLBACK_TRIPLEDOT=ON
"" for all platforms except Cygwin where its set to "cygwin_" and Mingw where
it is set to "mingw_". Updated osgDB::Registry to look for these for the plugins.
Updated the osgintrospection example to search for these names as well.
installed in /opt/local/include on my system (courtesy of DarwinPorts). I've added a CMakeModule to
look for zlib.h and the library in various places. The files are attached."
