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."
according to the OpenSceneGraph/CMakeLists.txt and the include/osg/Version settings.
These changes mean that the 1.9.5 release will have a libs/osgPlugins-1.9.5 directory.
and the configuration file template use by the command is the second file.
The command use the cmake_install.cmake file which list all file installed by the install target.
this issue come from the CMake FAQ"
the osgsimpleviewerQt4 example in my Visual studio solutions... After
looking into it it seems that you cannot have both Qt3 and Qt4
enabled. After modifying the root CMakeLists.txt to use :
FIND_PACKAGE(Qt) which should ask you to choose betwwen Qt3 and Qt4
if you have both
instead of :
FIND_PACKAGE(Qt3)
FIND_PACKAGE(Qt4)
I had the project generated. But then due to the way CMake handles Qt4
I had to modify osgsimpleviewerQt4's CMakeLists.txt to have the binary
link with QtOpengl4. "
"
Here are more changes for the CMake scripts:
- I removed CMAKE_INSTALL_PREFIX in FindOpenThreads as a follow up to
the discussion thread.
- I introduced an experimental CMAKE_PREFIX_PATH to replace it.
- I added CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, and
CMAKE_LIBRARY_PATH to the CMake GUI so users can enter values there
instead of in the environment.
- I added OPENSCENEGRAPH_*_VERSION variables (MAJOR, MINOR, PATCH).
These should be kept up-to-date with the real version numbers. Mac
bundles like to have version information so users can find out the
version they are running through standard About panels and also
automated system reporters for troubleshooting/bug tracking. In
theory, this information could be used for library versioning.
We should do the same for OpenThreads, but I forgot about it.
- I added some Mac Info.plist stuff (which uses the version information).
"
I was using ${FOO_CONFIG_HAS_BEEN_RUN_BEFORE} instead of just
FOO_HAS_BEEN_RUN_BEFORE.
In this case, it happened to work out to still be correct, but in
general it shouldn't have the ${}. (I really hate this syntax.)"
a bug regarding when to set the debug version. It waited until both
include and library were set, but it shouldn't wait on include.
Also added a fix to the optional warning flags."
"
Changes include:
A internal cache flag that can be used to detect if this is the first
time running the CMake configuration. This is needed to work around
stupid CMake UI shortcomings about the UI not reflecting anything you
SET unless you use FORCE. But if you use FORCE, you override anything
the user may try to set/override unless you have an exception check.
It turns out the exception check you need is often the first-run
check. This flag is potentially useful for other things too.
An optional switch that turns on more aggressive warnings based on
your compiler.
Some Apple specific stuff for detecting the OS version and enabling
Universal Binaries (and some additional compiler flags that are good
but gcc version dependent). The version check code is unfortunately
really fragile. I need to lobby CMake to return the OS X version
number for us. FYI, building Universal will fail with the current
CMake release due to a bug, but is now fixed in CVS.
"
It should not be introusive to any other palatform apart MSVC, but in order to link to debug-specific libs
I had to change plugins CMakeLists to differentiate debug/release linkage, I have used the same macro used in core libs
Now the macro used for plugin and examples linking test for existance of TARGET_LIBRARIES_VARS
that holds the names of the variables that have to be used for linking"
