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

390 lines
19 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
#######################################################################################################
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 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(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
TARGET_LINK_LIBRARIES(${TRGTNAME} ${ARGN})
ELSE(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
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)
ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
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 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
######################################################################
#
# This set up the libraries to link to, it assumes there are two variable: one common for a group of examples or plagins
# 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
#
Moved the TARGET_NAME setting into the OsgMacroUtils.cmake.
2007-03-20 01:24:19 +08:00
MACRO(SETUP_PLUGIN PLUGIN_NAME)
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 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(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
IF(NOT MSVC_IDE)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "${OSG_PLUGINS}/")
ELSE(NOT MSVC_IDE)
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
IF(MSVC_VERSION LESS 1600)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "../${OSG_PLUGINS}/")
ENDIF()
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(NOT MSVC_IDE)
ELSE(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
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)
ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
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}")
Introduced VERSION and SOVERSION'ing of libraries.
2007-05-21 01:38:11 +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
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 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 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
IF(MSVC_VERSION LESS 1600)
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(${TARGET_TARGETNAME} PROPERTIES PREFIX "../")
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
ENDIF()
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 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 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 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(${LIB_NAME} PROPERTIES PREFIX "../bin/${LIB_PREFIX}${LIB_SOVERSION}-")
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
IF (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
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"
)
ENDIF (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
ELSE(NOT MSVC_IDE)
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
IF(MSVC_VERSION LESS 1600)
SET_TARGET_PROPERTIES(${LIB_NAME} PROPERTIES PREFIX "../../bin/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
ENDIF()
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