FGFS-4.1/OpenSceneGraph
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
058eef0555
OpenSceneGraph/CMakeModules/OsgMacroUtils.cmake

524 lines
25 KiB
CMake
Raw Normal View History

From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
#######################################################################################################
# macro for linking libraries that come from Findxxxx commands, so there is a variable that contains the
# full path of the library name. in order to differentiate release and debug, this macro get the
# NAME of the variables, so the macro gets as arguments the target name and the following list of parameters
# is intended as a list of variable names each one containing the path of the libraries to link to
From David Fries,"We are needing to compile Debug, Release, and MinSizeWithDebInfo, but 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."
2010-03-11 01:19:35 +08:00
# The existance of a variable name with _DEBUG appended is tested and, in case it' s value is used
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
# for linking to when in debug mode
# the content of this library for linking when in debugging
#######################################################################################################
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
# VALID_BUILDER_VERSION: used for replacing CMAKE_VERSION (available in v2.6.3 RC9) and VERSION_GREATER/VERSION_LESS (available in 2.6.2 RC4).
# This can be replaced by "IF(${CMAKE_VERSION} VERSION_LESS "x.y.z")" from 2.6.4.
SET(VALID_BUILDER_VERSION OFF)
MACRO(BUILDER_VERSION_GREATER MAJOR_VER MINOR_VER PATCH_VER)
SET(VALID_BUILDER_VERSION OFF)
IF(CMAKE_MAJOR_VERSION GREATER ${MAJOR_VER})
SET(VALID_BUILDER_VERSION ON)
ELSEIF(CMAKE_MAJOR_VERSION EQUAL ${MAJOR_VER})
IF(CMAKE_MINOR_VERSION GREATER ${MINOR_VER})
SET(VALID_BUILDER_VERSION ON)
ELSEIF(CMAKE_MINOR_VERSION EQUAL ${MINOR_VER})
IF(CMAKE_PATCH_VERSION GREATER ${PATCH_VER})
SET(VALID_BUILDER_VERSION ON)
ENDIF(CMAKE_PATCH_VERSION GREATER ${PATCH_VER})
ENDIF()
ENDIF()
ENDMACRO(BUILDER_VERSION_GREATER MAJOR_VER MINOR_VER PATCH_VER)
# CMAKE24: if CMake version is <2.6.0.
SET(CMAKE24 OFF)
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} LESS 5)
SET(CMAKE24 ON)
ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} LESS 5)
# CMAKE_VERSION_TEST: Define whether "IF(${CMAKE_VERSION} VERSION_LESS "x.y.z")" can be used or not.
BUILDER_VERSION_GREATER(2 6 3)
SET(CMAKE_VERSION_TEST ${VALID_BUILDER_VERSION}) # >= 2.6.4
SET(VALID_BUILDER_VERSION OFF)
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
MACRO(LINK_WITH_VARIABLES TRGTNAME)
Fixed tabbing
2007-04-27 17:49:28 +08:00
FOREACH(varname ${ARGN})
IF(${varname}_DEBUG)
TARGET_LINK_LIBRARIES(${TRGTNAME} optimized "${${varname}}" debug "${${varname}_DEBUG}")
ELSE(${varname}_DEBUG)
TARGET_LINK_LIBRARIES(${TRGTNAME} "${${varname}}" )
ENDIF(${varname}_DEBUG)
ENDFOREACH(varname)
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
ENDMACRO(LINK_WITH_VARIABLES TRGTNAME)
MACRO(LINK_INTERNAL TRGTNAME)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
IF(NOT CMAKE24)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
TARGET_LINK_LIBRARIES(${TRGTNAME} ${ARGN})
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
ELSE(NOT CMAKE24)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
FOREACH(LINKLIB ${ARGN})
IF(MSVC AND OSG_MSVC_VERSIONED_DLL)
#when using versioned names, the .dll name differ from .lib name, there is a problem with that:
#CMake 2.4.7, at least seem to use PREFIX instead of IMPORT_PREFIX for computing linkage info to use into projects,
# so we full path name to specify linkage, this prevent automatic inferencing of dependencies, so we add explicit depemdencies
#to library targets used
From David Fries,"We are needing to compile Debug, Release, and MinSizeWithDebInfo, but 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."
2010-03-11 01:19:35 +08:00
TARGET_LINK_LIBRARIES(${TRGTNAME} optimized "${OUTPUT_LIBDIR}/${LINKLIB}${CMAKE_RELEASE_POSTFIX}.lib" debug "${OUTPUT_LIBDIR}/${LINKLIB}${CMAKE_DEBUG_POSTFIX}.lib")
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
ADD_DEPENDENCIES(${TRGTNAME} ${LINKLIB})
ELSE(MSVC AND OSG_MSVC_VERSIONED_DLL)
From David Fries,"We are needing to compile Debug, Release, and MinSizeWithDebInfo, but 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."
2010-03-11 01:19:35 +08:00
TARGET_LINK_LIBRARIES(${TRGTNAME} optimized "${LINKLIB}${CMAKE_RELEASE_POSTFIX}" debug "${LINKLIB}${CMAKE_DEBUG_POSTFIX}")
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
ENDIF(MSVC AND OSG_MSVC_VERSIONED_DLL)
ENDFOREACH(LINKLIB)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
ENDIF(NOT CMAKE24)
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
ENDMACRO(LINK_INTERNAL TRGTNAME)
MACRO(LINK_EXTERNAL TRGTNAME)
Fixed tabbing
2007-04-27 17:49:28 +08:00
FOREACH(LINKLIB ${ARGN})
TARGET_LINK_LIBRARIES(${TRGTNAME} "${LINKLIB}" )
ENDFOREACH(LINKLIB)
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
ENDMACRO(LINK_EXTERNAL TRGTNAME)
#######################################################################################################
Moved the OpenThreads link locally to each lib
2007-05-03 18:06:38 +08:00
# macro for common setup of core libraries: it links OPENGL_LIBRARIES in undifferentiated mode
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
#######################################################################################################
MACRO(LINK_CORELIB_DEFAULT CORELIB_NAME)
Copied libutil and libtess implementations in form Mesa 7.9/src/glu into the src/osg/glu, 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.
2010-10-06 22:44:52 +08:00
#SET(ALL_GL_LIBRARIES ${OPENGL_LIBRARIES})
SET(ALL_GL_LIBRARIES ${OPENGL_gl_LIBRARY})
Added EGL support into build system for GLES1 + GLES2. Added EGL support into GraphicsWindowX11.
2009-10-30 23:17:38 +08:00
IF (OSG_GLES1_AVAILABLE OR OSG_GLES2_AVAILABLE)
SET(ALL_GL_LIBRARIES ${ALL_GL_LIBRARIES} ${OPENGL_egl_LIBRARY})
ENDIF()
LINK_EXTERNAL(${CORELIB_NAME} ${ALL_GL_LIBRARIES})
Introduced VERSION and SOVERSION'ing of libraries.
2007-05-21 01:38:11 +08:00
LINK_WITH_VARIABLES(${CORELIB_NAME} OPENTHREADS_LIBRARY)
IF(OPENSCENEGRAPH_SONAMES)
SET_TARGET_PROPERTIES(${CORELIB_NAME} PROPERTIES VERSION ${OPENSCENEGRAPH_VERSION} SOVERSION ${OPENSCENEGRAPH_SOVERSION})
ENDIF(OPENSCENEGRAPH_SONAMES)
From Tassilo Glander,"I patched the cmake configuration to support folders, which are really handy to organize the many projects in the OSG solution into examples, applications and core libs in the IDE. 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"
2011-03-09 21:05:59 +08:00
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
ENDMACRO(LINK_CORELIB_DEFAULT CORELIB_NAME)
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
#######################################################################################################
# macro for common setup of plugins, examples and applications it expect some variables to be set:
# either within the local CMakeLists or higher in hierarchy
# TARGET_NAME is the name of the folder and of the actually .exe or .so or .dll
# TARGET_TARGETNAME is the name of the target , this get buit out of a prefix, if present and TARGET_TARGETNAME
# TARGET_SRC are the sources of the target
# TARGET_H are the eventual headers of the target
# TARGET_LIBRARIES are the libraries to link to that are internal to the project and have d suffix for debug
# TARGET_EXTERNAL_LIBRARIES are external libraries and are not differentiated with d suffix
# TARGET_LABEL is the label IDE should show up for targets
##########################################################################################################
MACRO(SETUP_LINK_LIBRARIES)
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
######################################################################
#
From Tassilo Glander,"I patched the cmake configuration to support folders, which are really handy to organize the many projects in the OSG solution into examples, applications and core libs in the IDE. 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"
2011-03-09 21:05:59 +08:00
# This set up the libraries to link to, it assumes there are two variable: one common for a group of examples or plugins
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
# kept in the variable TARGET_COMMON_LIBRARIES and an example or plugin specific kept in TARGET_ADDED_LIBRARIES
# they are combined in a single list checked for unicity
# the suffix ${CMAKE_DEBUG_POSTFIX} is used for differentiating optimized and debug
#
# a second variable TARGET_EXTERNAL_LIBRARIES hold the list of libraries not differentiated between debug and optimized
##################################################################################
SET(TARGET_LIBRARIES ${TARGET_COMMON_LIBRARIES})
FOREACH(LINKLIB ${TARGET_ADDED_LIBRARIES})
Fixed tabbing
2007-04-27 17:49:28 +08:00
SET(TO_INSERT TRUE)
FOREACH (value ${TARGET_COMMON_LIBRARIES})
IF (${value} STREQUAL ${LINKLIB})
SET(TO_INSERT FALSE)
ENDIF (${value} STREQUAL ${LINKLIB})
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
ENDFOREACH (value ${TARGET_COMMON_LIBRARIES})
Fixed tabbing
2007-04-27 17:49:28 +08:00
IF(TO_INSERT)
LIST(APPEND TARGET_LIBRARIES ${LINKLIB})
ENDIF(TO_INSERT)
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, 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"
2007-03-26 21:02:38 +08:00
ENDFOREACH(LINKLIB)
Copied libutil and libtess implementations in form Mesa 7.9/src/glu into the src/osg/glu, 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.
2010-10-06 22:44:52 +08:00
#SET(ALL_GL_LIBRARIES ${OPENGL_LIBRARIES})
SET(ALL_GL_LIBRARIES ${OPENGL_gl_LIBRARY})
Added EGL support into build system for GLES1 + GLES2. Added EGL support into GraphicsWindowX11.
2009-10-30 23:17:38 +08:00
IF (OSG_GLES1_AVAILABLE OR OSG_GLES2_AVAILABLE)
SET(ALL_GL_LIBRARIES ${ALL_GL_LIBRARIES} ${OPENGL_egl_LIBRARY})
ENDIF()
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
# FOREACH(LINKLIB ${TARGET_LIBRARIES})
# TARGET_LINK_LIBRARIES(${TARGET_TARGETNAME} optimized ${LINKLIB} debug "${LINKLIB}${CMAKE_DEBUG_POSTFIX}")
# ENDFOREACH(LINKLIB)
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
LINK_INTERNAL(${TARGET_TARGETNAME} ${TARGET_LIBRARIES})
From Mourad Boufarguine, "Some others modified CMake scripts : - 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"
2010-03-05 20:43:03 +08:00
# FOREACH(LINKLIB ${TARGET_EXTERNAL_LIBRARIES})
# TARGET_LINK_LIBRARIES(${TARGET_TARGETNAME} ${LINKLIB})
# ENDFOREACH(LINKLIB)
TARGET_LINK_LIBRARIES(${TARGET_TARGETNAME} ${TARGET_EXTERNAL_LIBRARIES})
Fixed tabbing
2007-04-27 17:49:28 +08:00
IF(TARGET_LIBRARIES_VARS)
LINK_WITH_VARIABLES(${TARGET_TARGETNAME} ${TARGET_LIBRARIES_VARS})
ENDIF(TARGET_LIBRARIES_VARS)
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
IF(MSVC AND OSG_MSVC_VERSIONED_DLL)
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
#when using full path name to specify linkage, it seems that already linked libs must be specified
Added EGL support into build system for GLES1 + GLES2. Added EGL support into GraphicsWindowX11.
2009-10-30 23:17:38 +08:00
LINK_EXTERNAL(${TARGET_TARGETNAME} ${ALL_GL_LIBRARIES})
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
ENDIF(MSVC AND OSG_MSVC_VERSIONED_DLL)
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
ENDMACRO(SETUP_LINK_LIBRARIES)
############################################################################################
# this is the common set of command for all the plugins
#
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
# Sets the output directory property for CMake >= 2.6.0, giving an output path RELATIVE to default one
MACRO(SET_OUTPUT_DIR_PROPERTY_260 TARGET_TARGETNAME RELATIVE_OUTDIR)
BUILDER_VERSION_GREATER(2 8 0)
IF(NOT VALID_BUILDER_VERSION)
# If CMake <= 2.8.0 (Testing CMAKE_VERSION is possible in >= 2.6.4)
IF(MSVC_IDE)
# Using the "prefix" hack
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "../${RELATIVE_OUTDIR}/")
ELSE(MSVC_IDE)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "${RELATIVE_OUTDIR}/")
ENDIF(MSVC_IDE)
ELSE(NOT VALID_BUILDER_VERSION)
# Using the output directory properties
# Global properties (All generators but VS & Xcode)
FILE(TO_CMAKE_PATH TMPVAR "CMAKE_ARCHIVE_OUTPUT_DIRECTORY/${RELATIVE_OUTDIR}")
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES ARCHIVE_OUTPUT_DIRECTORY "${TMPVAR}")
FILE(TO_CMAKE_PATH TMPVAR "CMAKE_RUNTIME_OUTPUT_DIRECTORY/${RELATIVE_OUTDIR}")
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES RUNTIME_OUTPUT_DIRECTORY "${TMPVAR}")
FILE(TO_CMAKE_PATH TMPVAR "CMAKE_LIBRARY_OUTPUT_DIRECTORY/${RELATIVE_OUTDIR}")
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${TMPVAR}")
# Per-configuration property (VS, Xcode)
FOREACH(CONF ${CMAKE_CONFIGURATION_TYPES}) # For each configuration (Debug, Release, MinSizeRel... and/or anything the user chooses)
STRING(TOUPPER "${CONF}" CONF) # Go uppercase (DEBUG, RELEASE...)
# We use "FILE(TO_CMAKE_PATH", to create nice looking paths
FILE(TO_CMAKE_PATH "${CMAKE_ARCHIVE_OUTPUT_DIRECTORY_${CONF}}/${RELATIVE_OUTDIR}" TMPVAR)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES "ARCHIVE_OUTPUT_DIRECTORY_${CONF}" "${TMPVAR}")
FILE(TO_CMAKE_PATH "${CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONF}}/${RELATIVE_OUTDIR}" TMPVAR)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES "RUNTIME_OUTPUT_DIRECTORY_${CONF}" "${TMPVAR}")
FILE(TO_CMAKE_PATH "${CMAKE_LIBRARY_OUTPUT_DIRECTORY_${CONF}}/${RELATIVE_OUTDIR}" TMPVAR)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES "LIBRARY_OUTPUT_DIRECTORY_${CONF}" "${TMPVAR}")
ENDFOREACH(CONF ${CMAKE_CONFIGURATION_TYPES})
ENDIF(NOT VALID_BUILDER_VERSION)
ENDMACRO(SET_OUTPUT_DIR_PROPERTY_260 TARGET_TARGETNAME RELATIVE_OUTDIR)
From Rafa Gaitan, "I have added the macro SETUP_LIBRARY, similar to SETUP_PLUGIN or 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. "
2011-03-08 21:51:13 +08:00
#######################################################################################################
# macro for common setup of libraries it expect some variables to be set:
# either within the local CMakeLists or higher in hierarchy
# LIB_NAME is the name of the target library
# TARGET_SRC are the sources of the target
# TARGET_H are the eventual headers of the target
From Mattias Helsing, "Fixes installation of the osgViewer headers that got broken with rev 12208 and 12231. The windowing system specific headers under include/osgViewer/api/<system> are again installed under include/osgViewer/api/<system> Works in recent ubuntu with cmake-2.8.4 and msvc2010 with cmake-2.8.2"
2011-04-22 01:16:27 +08:00
# TARGET_H_NO_MODULE_INSTALL are headers that belong to target but shouldn't get installed by the ModuleInstall script
From Rafa Gaitan, "I have added the macro SETUP_LIBRARY, similar to SETUP_PLUGIN or 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. "
2011-03-08 21:51:13 +08:00
# TARGET_LIBRARIES are the libraries to link to that are internal to the project and have d suffix for debug
# TARGET_EXTERNAL_LIBRARIES are external libraries and are not differentiated with d suffix
# TARGET_LABEL is the label IDE should show up for targets
##########################################################################################################
MACRO(SETUP_LIBRARY LIB_NAME)
From Rafa Gaitan and Jorge Izquierdo, build support for Android NDK. "- 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."
2011-03-09 00:35:37 +08:00
IF(ANDROID)
SETUP_ANDROID_LIBRARY(${LIB_NAME})
ELSE()
SET(TARGET_NAME ${LIB_NAME} )
SET(TARGET_TARGETNAME ${LIB_NAME} )
ADD_LIBRARY(${LIB_NAME}
${OPENSCENEGRAPH_USER_DEFINED_DYNAMIC_OR_STATIC}
${TARGET_H}
From Mattias Helsing, "Fixes installation of the osgViewer headers that got broken with rev 12208 and 12231. The windowing system specific headers under include/osgViewer/api/<system> are again installed under include/osgViewer/api/<system> Works in recent ubuntu with cmake-2.8.4 and msvc2010 with cmake-2.8.2"
2011-04-22 01:16:27 +08:00
${TARGET_H_NO_MODULE_INSTALL}
From Rafa Gaitan and Jorge Izquierdo, build support for Android NDK. "- 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."
2011-03-09 00:35:37 +08:00
${TARGET_SRC}
)
From Mourad Boufarguine, "I gave projects folders in VS a try, it works for applications, plugins and examples but not for the osg core libraries. Attached OsgMacroUtils.cmake is a tiny fix for this. OpenThreads is addressed seperately."
2011-03-10 22:44:49 +08:00
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES FOLDER "OSG Core")
From Rafa Gaitan and Jorge Izquierdo, build support for Android NDK. "- 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."
2011-03-09 00:35:37 +08:00
IF(TARGET_LABEL)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PROJECT_LABEL "${TARGET_LABEL}")
ENDIF(TARGET_LABEL)
From Rafa Gaitan, "I have added the macro SETUP_LIBRARY, similar to SETUP_PLUGIN or 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. "
2011-03-08 21:51:13 +08:00
From Rafa Gaitan and Jorge Izquierdo, build support for Android NDK. "- 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."
2011-03-09 00:35:37 +08:00
IF(TARGET_LIBRARIES)
LINK_INTERNAL(${LIB_NAME} ${TARGET_LIBRARIES})
ENDIF()
IF(TARGET_EXTERNAL_LIBRARIES)
LINK_EXTERNAL(${LIB_NAME} ${TARGET_EXTERNAL_LIBRARIES})
ENDIF()
IF(TARGET_LIBRARIES_VARS)
LINK_WITH_VARIABLES(${LIB_NAME} ${TARGET_LIBRARIES_VARS})
ENDIF(TARGET_LIBRARIES_VARS)
LINK_CORELIB_DEFAULT(${LIB_NAME})
From Rafa Gaitan, "I have added the macro SETUP_LIBRARY, similar to SETUP_PLUGIN or 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. "
2011-03-08 21:51:13 +08:00
From Rafa Gaitan and Jorge Izquierdo, build support for Android NDK. "- 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."
2011-03-09 00:35:37 +08:00
ENDIF()
From Mourad Boufarguine, "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)"
2011-03-11 18:24:12 +08:00
INCLUDE(ModuleInstall OPTIONAL)
From Rafa Gaitan, "I have added the macro SETUP_LIBRARY, similar to SETUP_PLUGIN or 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. "
2011-03-08 21:51:13 +08:00
ENDMACRO(SETUP_LIBRARY LIB_NAME)
Moved the TARGET_NAME setting into the OsgMacroUtils.cmake.
2007-03-20 01:24:19 +08:00
MACRO(SETUP_PLUGIN PLUGIN_NAME)
From Rafa Gaitan and Jorge Izquierdo, build support for Android NDK. "- 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."
2011-03-09 00:35:37 +08:00
IF(ANDROID)
SETUP_ANDROID_LIBRARY(${TARGET_DEFAULT_PREFIX}${PLUGIN_NAME})
ELSE()
Moved the TARGET_NAME setting into the OsgMacroUtils.cmake.
2007-03-20 01:24:19 +08:00
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
SET(TARGET_NAME ${PLUGIN_NAME} )
Moved the TARGET_NAME setting into the OsgMacroUtils.cmake.
2007-03-20 01:24:19 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
#MESSAGE("in -->SETUP_PLUGIN<-- ${TARGET_NAME}-->${TARGET_SRC} <--> ${TARGET_H}<--")
## we have set up the target label and targetname by taking into account global prfix (osgdb_)
IF(NOT TARGET_TARGETNAME)
SET(TARGET_TARGETNAME "${TARGET_DEFAULT_PREFIX}${TARGET_NAME}")
ENDIF(NOT TARGET_TARGETNAME)
IF(NOT TARGET_LABEL)
SET(TARGET_LABEL "${TARGET_DEFAULT_LABEL_PREFIX} ${TARGET_NAME}")
ENDIF(NOT TARGET_LABEL)
From Mattias Helsing, "I have developed the earlier cpack example a bit. Perhaps you could 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)"
2008-12-12 19:01:09 +08:00
## plugins gets put in libopenscenegraph by default
IF(${ARGC} GREATER 1)
SET(PACKAGE_COMPONENT libopenscenegraph-${ARGV1})
ELSE(${ARGC} GREATER 1)
SET(PACKAGE_COMPONENT libopenscenegraph)
ENDIF(${ARGC} GREATER 1)
Added VisualStudio versioning info to plugins
2009-02-20 21:58:44 +08:00
# Add the VisualStudio versioning info
SET(TARGET_SRC ${TARGET_SRC} ${OPENSCENEGRAPH_VERSIONINFO_RC})
Fixed tabbing
2007-04-27 17:49:28 +08:00
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
# here we use the command to generate the library
Added automatic building of plugins as static when dynamic build is switch off.
2007-05-24 03:25:54 +08:00
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} MODULE ${TARGET_SRC} ${TARGET_H})
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_LIBRARY(${TARGET_TARGETNAME} STATIC ${TARGET_SRC} ${TARGET_H})
ENDIF(DYNAMIC_OPENSCENEGRAPH)
Fixed tabbing
2007-04-27 17:49:28 +08:00
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
#not sure if needed, but for plugins only Msvc need the d suffix
Fixed tabbing
2007-04-27 17:49:28 +08:00
IF(NOT MSVC)
From Mathieu Marache, 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
2008-05-28 20:49:47 +08:00
IF(NOT UNIX)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX "")
ENDIF(NOT UNIX)
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
ELSE(NOT MSVC)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
IF(NOT CMAKE24)
SET_OUTPUT_DIR_PROPERTY_260(${TARGET_TARGETNAME} "${OSG_PLUGINS}") # Sets the ouput to be /osgPlugin-X.X.X ; also ensures the /Debug /Release are removed
ELSE(NOT CMAKE24)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
IF(OSG_MSVC_VERSIONED_DLL)
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
#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,
#it is hardcoded, we should compute OUTPUT_BINDIR position relative to OUTPUT_LIBDIR ... to be implemented
#changing bin to something else breaks this hack
#the dll are placed in bin/${OSG_PLUGINS}
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
IF(NOT MSVC_IDE)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "../bin/${OSG_PLUGINS}/")
ELSE(NOT MSVC_IDE)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "../../bin/${OSG_PLUGINS}/" IMPORT_PREFIX "../")
ENDIF(NOT MSVC_IDE)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
ELSE(OSG_MSVC_VERSIONED_DLL)
#in standard mode (unversioned) the .lib and .dll are placed in lib/<debug or release>/${OSG_PLUGINS}.
#here the PREFIX property has been used, the same result would be accomplidhe by prepending ${OSG_PLUGINS}/ to OUTPUT_NAME target property
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "${OSG_PLUGINS}/")
ENDIF(OSG_MSVC_VERSIONED_DLL)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
ENDIF(NOT CMAKE24)
Fixed tabbing
2007-04-27 17:49:28 +08:00
ENDIF(NOT MSVC)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PROJECT_LABEL "${TARGET_LABEL}")
From Tassilo Glander,"I patched the cmake configuration to support folders, which are really handy to organize the many projects in the OSG solution into examples, applications and core libs in the IDE. 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"
2011-03-09 21:05:59 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES FOLDER "Plugins")
Fixed tabbing
2007-04-27 17:49:28 +08:00
SETUP_LINK_LIBRARIES()
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
Added support for version of the osgPlugins directory, which now gets versioned 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.
2007-05-20 20:29:11 +08:00
#the installation path are differentiated for win32 that install in bib versus other architecture that install in lib${LIB_POSTFIX}/${OSG_PLUGINS}
Fixed tabbing
2007-04-27 17:49:28 +08:00
IF(WIN32)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
INSTALL(TARGETS ${TARGET_TARGETNAME}
From Mattias Helsing, "I have developed the earlier cpack example a bit. Perhaps you could 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)"
2008-12-12 19:01:09 +08:00
RUNTIME DESTINATION bin COMPONENT ${PACKAGE_COMPONENT}
ARCHIVE DESTINATION lib/${OSG_PLUGINS} COMPONENT libopenscenegraph-dev
LIBRARY DESTINATION bin/${OSG_PLUGINS} COMPONENT ${PACKAGE_COMPONENT})
Fixed tabbing
2007-04-27 17:49:28 +08:00
ELSE(WIN32)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
INSTALL(TARGETS ${TARGET_TARGETNAME}
From Mattias Helsing, "I have developed the earlier cpack example a bit. Perhaps you could 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)"
2008-12-12 19:01:09 +08:00
RUNTIME DESTINATION bin COMPONENT ${PACKAGE_COMPONENT}
ARCHIVE DESTINATION lib${LIB_POSTFIX}/${OSG_PLUGINS} COMPONENT libopenscenegraph-dev
LIBRARY DESTINATION lib${LIB_POSTFIX}/${OSG_PLUGINS} COMPONENT ${PACKAGE_COMPONENT})
Fixed tabbing
2007-04-27 17:49:28 +08:00
ENDIF(WIN32)
From Rafa Gaitan and Jorge Izquierdo, build support for Android NDK. "- 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."
2011-03-09 00:35:37 +08:00
ENDIF()
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
ENDMACRO(SETUP_PLUGIN)
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
#################################################################################################################
# this is the macro for example and application setup
###########################################################
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
From Eric Wing, "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?"
2007-04-12 17:33:24 +08:00
MACRO(SETUP_EXE IS_COMMANDLINE_APP)
Fixed tabbing
2007-04-27 17:49:28 +08:00
#MESSAGE("in -->SETUP_EXE<-- ${TARGET_NAME}-->${TARGET_SRC} <--> ${TARGET_H}<--")
IF(NOT TARGET_TARGETNAME)
SET(TARGET_TARGETNAME "${TARGET_DEFAULT_PREFIX}${TARGET_NAME}")
ENDIF(NOT TARGET_TARGETNAME)
IF(NOT TARGET_LABEL)
SET(TARGET_LABEL "${TARGET_DEFAULT_LABEL_PREFIX} ${TARGET_NAME}")
ENDIF(NOT TARGET_LABEL)
IF(${IS_COMMANDLINE_APP})
From Luigi Calori, build fixes for Win32 build osg WxWidgets example
2007-05-25 21:15:00 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
ADD_EXECUTABLE(${TARGET_TARGETNAME} ${TARGET_SRC} ${TARGET_H})
From Luigi Calori, build fixes for Win32 build osg WxWidgets example
2007-05-25 21:15:00 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
ELSE(${IS_COMMANDLINE_APP})
From Luigi Calori, build fixes for Win32 build osg WxWidgets example
2007-05-25 21:15:00 +08:00
From Eric Wing, " 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). "
2007-04-27 18:29:48 +08:00
IF(APPLE)
# SET(MACOSX_BUNDLE_LONG_VERSION_STRING "${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION}")
# Short Version is the "marketing version". It is the version
# the user sees in an information panel.
SET(MACOSX_BUNDLE_SHORT_VERSION_STRING "${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION}")
# Bundle version is the version the OS looks at.
SET(MACOSX_BUNDLE_BUNDLE_VERSION "${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION}")
SET(MACOSX_BUNDLE_GUI_IDENTIFIER "org.openscenegraph.${TARGET_TARGETNAME}" )
SET(MACOSX_BUNDLE_BUNDLE_NAME "${TARGET_NAME}" )
# SET(MACOSX_BUNDLE_ICON_FILE "myicon.icns")
# SET(MACOSX_BUNDLE_COPYRIGHT "")
# SET(MACOSX_BUNDLE_INFO_STRING "Info string, localized?")
ENDIF(APPLE)
From Luigi Calori, build fixes for Win32 build osg WxWidgets example
2007-05-25 21:15:00 +08:00
Introduce OSG_BUILD_APPLICATION_BUNDLES option for OSX, defaulting to OFF.
2007-06-05 05:02:15 +08:00
IF(WIN32)
IF (REQUIRE_WINMAIN_FLAG)
SET(PLATFORM_SPECIFIC_CONTROL WIN32)
ENDIF(REQUIRE_WINMAIN_FLAG)
ENDIF(WIN32)
IF(APPLE)
IF(OSG_BUILD_APPLICATION_BUNDLES)
SET(PLATFORM_SPECIFIC_CONTROL MACOSX_BUNDLE)
ENDIF(OSG_BUILD_APPLICATION_BUNDLES)
ENDIF(APPLE)
ADD_EXECUTABLE(${TARGET_TARGETNAME} ${PLATFORM_SPECIFIC_CONTROL} ${TARGET_SRC} ${TARGET_H})
From Eric Wing, " 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). "
2007-04-27 18:29:48 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
ENDIF(${IS_COMMANDLINE_APP})
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PROJECT_LABEL "${TARGET_LABEL}")
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES OUTPUT_NAME ${TARGET_NAME})
From David Fries,"We are needing to compile Debug, Release, and MinSizeWithDebInfo, but 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."
2010-03-11 01:19:35 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_OUTPUT_NAME "${TARGET_NAME}${CMAKE_DEBUG_POSTFIX}")
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES RELEASE_OUTPUT_NAME "${TARGET_NAME}${CMAKE_RELEASE_POSTFIX}")
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES RELWITHDEBINFO_OUTPUT_NAME "${TARGET_NAME}${CMAKE_RELWITHDEBINFO_POSTFIX}")
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES MINSIZEREL_OUTPUT_NAME "${TARGET_NAME}${CMAKE_MINSIZEREL_POSTFIX}")
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
IF(MSVC_IDE AND OSG_MSVC_VERSIONED_DLL)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
SET_OUTPUT_DIR_PROPERTY_260(${TARGET_TARGETNAME} "") # Ensure the /Debug /Release are removed
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
ENDIF(MSVC_IDE AND OSG_MSVC_VERSIONED_DLL)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
SETUP_LINK_LIBRARIES()
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
ENDMACRO(SETUP_EXE)
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
From Eric Wing, "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?"
2007-04-12 17:33:24 +08:00
# Takes optional second argument (is_commandline_app?) in ARGV1
Moved the TARGET_NAME setting into the SETUP_APPLICATION/EXAMPLE macro
2007-03-20 01:18:59 +08:00
MACRO(SETUP_APPLICATION APPLICATION_NAME)
SET(TARGET_NAME ${APPLICATION_NAME} )
From Luigi Calori, improvements to handling of install under Unix
2007-03-09 22:54:41 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
IF(${ARGC} GREATER 1)
SET(IS_COMMANDLINE_APP ${ARGV1})
ELSE(${ARGC} GREATER 1)
SET(IS_COMMANDLINE_APP 0)
ENDIF(${ARGC} GREATER 1)
From Eric Wing, "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?"
2007-04-12 17:33:24 +08:00
SETUP_EXE(${IS_COMMANDLINE_APP})
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
From Tassilo Glander,"I patched the cmake configuration to support folders, which are really handy to organize the many projects in the OSG solution into examples, applications and core libs in the IDE. 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"
2011-03-09 21:05:59 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES FOLDER "Applications")
From Eric Sokolowsky, "I have made a number of changes intended to get a few things working better on OSX. However, since I'm still pretty new at Mac development and cmake I'm not entirely certain that the changes I have made are benign on other platforms. I have tested these changes on Leopard with CMake 2.6 generating Xcode 3.0 projects, compiling on ppc and i386 for 10.5 and 10.4, and on Linux (CentOS) and everything still seems to work ok. Here are the changes I made (against OSG svn as of this afternoon): - 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)"
2008-06-23 17:57:45 +08:00
IF(APPLE)
INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION bin BUNDLE DESTINATION bin)
ELSE(APPLE)
From Mattias Helsing, "I have developed the earlier cpack example a bit. Perhaps you could 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)"
2008-12-12 19:01:09 +08:00
INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION bin COMPONENT openscenegraph )
From Eric Sokolowsky, "I have made a number of changes intended to get a few things working better on OSX. However, since I'm still pretty new at Mac development and cmake I'm not entirely certain that the changes I have made are benign on other platforms. I have tested these changes on Leopard with CMake 2.6 generating Xcode 3.0 projects, compiling on ppc and i386 for 10.5 and 10.4, and on Linux (CentOS) and everything still seems to work ok. Here are the changes I made (against OSG svn as of this afternoon): - 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)"
2008-06-23 17:57:45 +08:00
ENDIF(APPLE)
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
ENDMACRO(SETUP_APPLICATION)
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
Added SETUP_COMMANDLINE_APPLICATION and SETUP_COMMANDLINE_EXAMPLE macros
2007-04-12 17:59:34 +08:00
MACRO(SETUP_COMMANDLINE_APPLICATION APPLICATION_NAME)
Fixed variable name dereference
2007-04-13 01:30:06 +08:00
SETUP_APPLICATION(${APPLICATION_NAME} 1)
Added SETUP_COMMANDLINE_APPLICATION and SETUP_COMMANDLINE_EXAMPLE macros
2007-04-12 17:59:34 +08:00
ENDMACRO(SETUP_COMMANDLINE_APPLICATION)
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
From Eric Wing, "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?"
2007-04-12 17:33:24 +08:00
# Takes optional second argument (is_commandline_app?) in ARGV1
Moved the TARGET_NAME setting into the SETUP_APPLICATION/EXAMPLE macro
2007-03-20 01:18:59 +08:00
MACRO(SETUP_EXAMPLE EXAMPLE_NAME)
SET(TARGET_NAME ${EXAMPLE_NAME} )
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
Fixed tabbing
2007-04-27 17:49:28 +08:00
IF(${ARGC} GREATER 1)
SET(IS_COMMANDLINE_APP ${ARGV1})
ELSE(${ARGC} GREATER 1)
SET(IS_COMMANDLINE_APP 0)
ENDIF(${ARGC} GREATER 1)
From Eric Wing, "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?"
2007-04-12 17:33:24 +08:00
SETUP_EXE(${IS_COMMANDLINE_APP})
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
From Tassilo Glander,"I patched the cmake configuration to support folders, which are really handy to organize the many projects in the OSG solution into examples, applications and core libs in the IDE. 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"
2011-03-09 21:05:59 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES FOLDER "Examples")
From Eric Sokolowsky, "I have made a number of changes intended to get a few things working better on OSX. However, since I'm still pretty new at Mac development and cmake I'm not entirely certain that the changes I have made are benign on other platforms. I have tested these changes on Leopard with CMake 2.6 generating Xcode 3.0 projects, compiling on ppc and i386 for 10.5 and 10.4, and on Linux (CentOS) and everything still seems to work ok. Here are the changes I made (against OSG svn as of this afternoon): - 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)"
2008-06-23 17:57:45 +08:00
IF(APPLE)
INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION share/OpenSceneGraph/bin BUNDLE DESTINATION share/OpenSceneGraph/bin )
ELSE(APPLE)
Changed the libopenscenegraph-core to be part of libopenscenegraph, and changed libopenscenegraph-examples to be part of openscenegraph-examples
2008-12-12 22:54:22 +08:00
INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION share/OpenSceneGraph/bin COMPONENT openscenegraph-examples )
From Eric Sokolowsky, "I have made a number of changes intended to get a few things working better on OSX. However, since I'm still pretty new at Mac development and cmake I'm not entirely certain that the changes I have made are benign on other platforms. I have tested these changes on Leopard with CMake 2.6 generating Xcode 3.0 projects, compiling on ppc and i386 for 10.5 and 10.4, and on Linux (CentOS) and everything still seems to work ok. Here are the changes I made (against OSG svn as of this afternoon): - 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)"
2008-06-23 17:57:45 +08:00
ENDIF(APPLE)
From Luigi Calori, move to using local CMakeLists.txt files and explicit file lists. From Robert Osfield, small ammendments of the above to seperate example and application installs, and fix the osgPlugins install directory.
2007-03-19 20:30:26 +08:00
ENDMACRO(SETUP_EXAMPLE)
From Luigi Calori, added marco support
2007-03-05 21:27:55 +08:00
Added SETUP_COMMANDLINE_APPLICATION and SETUP_COMMANDLINE_EXAMPLE macros
2007-04-12 17:59:34 +08:00
MACRO(SETUP_COMMANDLINE_EXAMPLE EXAMPLE_NAME)
Fixed variable name dereference
2007-04-13 01:30:06 +08:00
SETUP_EXAMPLE(${EXAMPLE_NAME} 1)
Added SETUP_COMMANDLINE_APPLICATION and SETUP_COMMANDLINE_EXAMPLE macros
2007-04-12 17:59:34 +08:00
ENDMACRO(SETUP_COMMANDLINE_EXAMPLE)
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
From Andy Skinner, added support for ot-soversion-OpenThreads.dll dll naming under Windows
2007-09-14 19:06:12 +08:00
# Takes two optional arguments -- osg prefix and osg version
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
MACRO(HANDLE_MSVC_DLL)
From Philip Lowman, post 1: "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."
2008-05-27 06:36:58 +08:00
#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,
#it is hardcoded, we should compute OUTPUT_BINDIR position relative to OUTPUT_LIBDIR ... to be implemented
#changing bin to something else breaks this hack
#the dll are versioned by prefixing the name with osg${OPENSCENEGRAPH_SOVERSION}-
From Andy Skinner, added support for ot-soversion-OpenThreads.dll dll naming under Windows
2007-09-14 19:06:12 +08:00
# LIB_PREFIX: use "osg" by default, else whatever we've been given.
IF(${ARGC} GREATER 0)
SET(LIB_PREFIX ${ARGV0})
ELSE(${ARGC} GREATER 0)
SET(LIB_PREFIX osg)
ENDIF(${ARGC} GREATER 0)
# LIB_SOVERSION: use OSG's soversion by default, else whatever we've been given
IF(${ARGC} GREATER 1)
SET(LIB_SOVERSION ${ARGV1})
ELSE(${ARGC} GREATER 1)
SET(LIB_SOVERSION ${OPENSCENEGRAPH_SOVERSION})
ENDIF(${ARGC} GREATER 1)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
SET_OUTPUT_DIR_PROPERTY_260(${LIB_NAME} "") # Ensure the /Debug /Release are removed
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
IF(NOT MSVC_IDE)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
IF (NOT CMAKE24)
BUILDER_VERSION_GREATER(2 8 0)
IF(NOT VALID_BUILDER_VERSION)
# If CMake < 2.8.1
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
ELSE(NOT VALID_BUILDER_VERSION)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "${LIB_PREFIX}${LIB_SOVERSION}-")
ENDIF(NOT VALID_BUILDER_VERSION)
ELSE (NOT CMAKE24)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
From Mathieu Marache, "I came across a bug when building OpenSceneGraph with 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."
2008-10-27 17:48:34 +08:00
SET(NEW_LIB_NAME "${OUTPUT_BINDIR}/${LIB_PREFIX}${LIB_SOVERSION}-${LIB_NAME}")
ADD_CUSTOM_COMMAND(
TARGET ${LIB_NAME}
POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy "${NEW_LIB_NAME}.lib" "${OUTPUT_LIBDIR}/${LIB_NAME}.lib"
COMMAND ${CMAKE_COMMAND} -E copy "${NEW_LIB_NAME}.exp" "${OUTPUT_LIBDIR}/${LIB_NAME}.exp"
COMMAND ${CMAKE_COMMAND} -E remove "${NEW_LIB_NAME}.lib"
COMMAND ${CMAKE_COMMAND} -E remove "${NEW_LIB_NAME}.exp"
)
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
ENDIF (NOT CMAKE24)
ELSE(NOT MSVC_IDE)
IF (NOT CMAKE24)
BUILDER_VERSION_GREATER(2 8 0)
IF(NOT VALID_BUILDER_VERSION)
# If CMake < 2.8.1
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "../../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
ELSE(NOT VALID_BUILDER_VERSION)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "${LIB_PREFIX}${LIB_SOVERSION}-")
ENDIF(NOT VALID_BUILDER_VERSION)
ELSE (NOT CMAKE24)
From Wang Rui, "The OSG book I'm working on will focus on helping beginners build 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. "
2010-04-21 00:27:54 +08:00
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "../../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
From Sukender, "As discussed in osg-users, I found output directories with CMake >= 2.8.1 are wrong under MSVC (As Chuck said, it's to be related to CMake, and not MSVC). 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 "
2010-11-09 22:39:32 +08:00
ENDIF (NOT CMAKE24)
From Mathieu Marache, "I came across a bug when building OpenSceneGraph with 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."
2008-10-27 17:48:34 +08:00
ENDIF(NOT MSVC_IDE)
From Rene Molenaar, "Using commandline build system nmake on windows does not work. 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. "
2008-02-18 23:26:46 +08:00
# SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "../../bin/osg${OPENSCENEGRAPH_SOVERSION}-")
# SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES IMPORT_PREFIX "../")
From Luigi Calori, introduction of versioning of dll's and placement of dll and plugins into bin directory during build.
2007-08-30 18:41:15 +08:00
ENDMACRO(HANDLE_MSVC_DLL)
Reference in New Issue Copy Permalink