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

358 lines
17 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
# The existance of a varibale name with _DEBUG appended is tested and, in case it' s value is used
# 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 Mattias Helsing, CMakeLists.txt changes: "I installed latest Cmake(2.6.1) on a new machine and got a CMP008 warning from cmake. This fix set up osg to use the old behaviour which have worked before. We might set this to NEW but I need to do more testing first. I'l be able to test this on winxp with msvc80/90 and ubuntu hardy with gcc-4.2. quote from cmake cvs log policy CMP0008 to decides how to treat full path libraries that do not appear to be valid library file names. Such libraries worked by accident in the VS IDE and Xcode generators with CMake 2.4 and below." OsgMarcroUtils.cmake changes: "On Philips suggestion truncated a redundant if/else construction in OsgMacroUtils to avoid developer warnings in cmake-2.6.1 concerning cmake policy CMP0008 which allows full paths to libraries only with valid library names "
2008-09-18 03:25:40 +08:00
TARGET_LINK_LIBRARIES(${TRGTNAME} optimized "${OUTPUT_LIBDIR}/${LINKLIB}.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)
TARGET_LINK_LIBRARIES(${TRGTNAME} optimized "${LINKLIB}" debug "${LINKLIB}${CMAKE_DEBUG_POSTFIX}")
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)
Fixed tabbing
2007-04-27 17:49:28 +08:00
LINK_EXTERNAL(${CORELIB_NAME} ${OPENGL_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)
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 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
FOREACH(LINKLIB ${TARGET_EXTERNAL_LIBRARIES})
Fixed tabbing
2007-04-27 17:49:28 +08:00
TARGET_LINK_LIBRARIES(${TARGET_TARGETNAME} ${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(LINKLIB)
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
LINK_EXTERNAL(${TARGET_TARGETNAME} ${OPENGL_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 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)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "../${OSG_PLUGINS}/")
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}
RUNTIME DESTINATION bin
ARCHIVE DESTINATION lib/${OSG_PLUGINS}
LIBRARY DESTINATION bin/${OSG_PLUGINS} )
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}
RUNTIME DESTINATION bin
ARCHIVE DESTINATION lib${LIB_POSTFIX}/${OSG_PLUGINS}
LIBRARY DESTINATION lib${LIB_POSTFIX}/${OSG_PLUGINS} )
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}")
From Paul Obermeier, "Please find enclosed the following 2 bug fixes: File osgShadow/Version.cpp, Line 25: const char* osgShaodowGetLibraryName() should be: const char* osgShadowGetLibraryName() File CMakeModules/OsgMacroUtils.cmake, Line 224: SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX ${CMAKE_DEBUG_POSTFIX}) should be: SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}") Otherwise setting CMAKE_DEBUG_POSTFIX to an empty string instead of "d" in the main CMakeLists.txt does not work under Linux. "
2007-12-18 02:38:21 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}")
Fixed tabbing
2007-04-27 17:49:28 +08:00
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES OUTPUT_NAME ${TARGET_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
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)
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "../")
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)
INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION bin )
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)
INSTALL(TARGETS ${TARGET_TARGETNAME} RUNTIME DESTINATION share/OpenSceneGraph/bin )
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 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/${LIB_PREFIX}${LIB_SOVERSION}-" IMPORT_PREFIX "../")
From Mathieu Marache, "I came across a bug when building OpenSceneGraph with MSVC_VERSIONED_DLL, NMake makefiles and CMake 2.6.2. The compilation fails because it tries to copy ot11-OpenThreads.lib to OpenThreads.lib which is valid for the 2.4.x era of CMake but not anymore in 2.6.x era. The provided file from the CMakeModules directory adds a tests on the CMake version and corrects this. Works for me now."
2008-10-27 17:48:34 +08:00
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