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"
