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.
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.
"
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"
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)"
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
"
- 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
"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."
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.
"
File osgShadow/Version.cpp, Line 25:
const char* osgShaodowGetLibraryName()
should be:
const char* osgShadowGetLibraryName()
File CMakeModules/OsgMacroUtils.cmake, Line 224:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX ${CMAKE_DEBUG_POSTFIX})
should be:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}")
Otherwise setting CMAKE_DEBUG_POSTFIX to an empty string instead of "d" in
the main CMakeLists.txt does not work under Linux.
"
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.
"
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).
"
"Attached is a patch allows access access to the CMake MACOSX_BUNDLE
option. Now SETUP_APPLICATION and SETUP_EXAMPLE take an additional
optional parameter that specifies if the program is a command line
application or a GUI application (think: IS_COMMANDLINE_APP). Passing
1 means true (is_commandline_app). Passing 0 or omitting the parameter
means false.
I changed the scripts for osgversion and osgunittests to support this
option because I believe they are command line apps. Are there any
others?"
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"
so I' ve set up a macro that uses the variable name expanded for linking, and test if a variable ${LINK_VAR_NAME}_DEBUG
like OPENTHREADS_LIBRARY_DEBUG exists and in case uses it for linking in debug mode.
I' ve also set up FindOpenThreads to set up these variables.
I had to edit the core libraries CMakeLists to add the calls to the macros used.
I' ve tested under MSVC"
