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

186 lines
6.1 KiB
CMake
Raw Normal View History

From Eric Wing and others, first cut of CMake build support
2007-03-04 21:05:33 +08:00
# OpenThreads is a C++ based threading library. Its largest userbase
# seems to OpenSceneGraph so you might notice I accept OSGDIR as an
# environment path.
# I consider this part of the Findosg* suite used to find OpenSceneGraph
# components.
# Each component is separate and you must opt in to each module.
#
# Locate OpenThreads
# This module defines
# OPENTHREADS_LIBRARY
# OPENTHREADS_FOUND, if false, do not try to link to OpenThreads
# OPENTHREADS_INCLUDE_DIR, where to find the headers
#
# $OPENTHREADS_DIR is an environment variable that would
# correspond to the ./configure --prefix=$OPENTHREADS_DIR
# used in building osg.
#
# Created by Eric Wing.
# Header files are presumed to be included like
# #include <OpenThreads/Thread>
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +08:00
# To make it easier for one-step automated configuration/builds,
# we leverage environmental paths. This is preferable
# to the -DVAR=value switches because it insulates the
# users from changes we may make in this script.
# It also offers a little more flexibility than setting
# the CMAKE_*_PATH since we can target specific components.
# However, the default CMake behavior will search system paths
# before anything else. This is problematic in the cases
# where you have an older (stable) version installed, but
# are trying to build a newer version.
# CMake doesn't offer a nice way to globally control this behavior
# so we have to do a nasty "double FIND_" in this module.
# The first FIND disables the CMAKE_ search paths and only checks
# the environmental paths.
# If nothing is found, then the second find will search the
# standard install paths.
# Explicit -DVAR=value arguments should still be able to override everything.
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
# Note: We have added an additional check for ${CMAKE_PREFIX_PATH}.
# This is not an official CMake variable, but one we are proposing be
# added to CMake. Be warned that this may go away or the variable name
# may change.
From Lugi Calori, tweaks to macros and addition of CMAKE_INSTALL_PREFIX to FindOpenThreads
2007-03-08 23:33:50 +08:00
From Eric Wing and others, first cut of CMake build support
2007-03-04 21:05:33 +08:00
FIND_PATH(OPENTHREADS_INCLUDE_DIR OpenThreads/Thread
Fixed tabbing
2007-04-27 17:49:28 +08:00
$ENV{OPENTHREADS_INCLUDE_DIR}
$ENV{OPENTHREADS_DIR}/include
$ENV{OPENTHREADS_DIR}
$ENV{OSG_INCLUDE_DIR}
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}
NO_DEFAULT_PATH
From Eric Wing and others, first cut of CMake build support
2007-03-04 21:05:33 +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(NOT OPENTHREADS_INCLUDE_DIR)
FIND_PATH(OPENTHREADS_INCLUDE_DIR OpenThreads/Thread
PATHS ${CMAKE_PREFIX_PATH} # Unofficial: We are proposing this.
PATH_SUFFIXES include
)
ENDIF(NOT OPENTHREADS_INCLUDE_DIR)
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +08:00
IF(NOT OPENTHREADS_INCLUDE_DIR)
Fixed tabbing
2007-04-27 17:49:28 +08:00
FIND_PATH(OPENTHREADS_INCLUDE_DIR OpenThreads/Thread
~/Library/Frameworks
/Library/Frameworks
/usr/local/include
/usr/include
/sw/include # Fink
/opt/local/include # DarwinPorts
/opt/csw/include # Blastwave
/opt/include
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
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ Manager\\Environment;OpenThreads_ROOT]/include
Fixed tabbing
2007-04-27 17:49:28 +08:00
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ Manager\\Environment;OSG_ROOT]/include
)
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +08:00
ENDIF(NOT OPENTHREADS_INCLUDE_DIR)
From Eric Wing and others, first cut of CMake build support
2007-03-04 21:05:33 +08:00
FIND_LIBRARY(OPENTHREADS_LIBRARY
Fixed tabbing
2007-04-27 17:49:28 +08:00
NAMES OpenThreads OpenThreadsWin32
PATHS
$ENV{OPENTHREADS_LIBRARY_DIR}
$ENV{OPENTHREADS_DIR}/lib64
$ENV{OPENTHREADS_DIR}/lib
$ENV{OPENTHREADS_DIR}
$ENV{OSG_LIBRARY_DIR}
$ENV{OSG_DIR}/lib64
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
NO_DEFAULT_PATH
From Luigi Calori, "when we link against something that comes out from a Find... we ususally have a variable <LINK_VAR_NAME>available like OPENTHREADS_LIBRARY, so I' ve set up a macro that uses the variable name expanded for linking, and test if a variable ${LINK_VAR_NAME}_DEBUG like OPENTHREADS_LIBRARY_DEBUG exists and in case uses it for linking in debug mode. I' ve also set up FindOpenThreads to set up these variables. I had to edit the core libraries CMakeLists to add the calls to the macros used. I' ve tested under MSVC"
2007-03-26 21:02:38 +08:00
)
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +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(NOT OPENTHREADS_LIBRARY)
FIND_LIBRARY(OPENTHREADS_LIBRARY
NAMES OpenThreads OpenThreadsWin32
PATHS ${CMAKE_PREFIX_PATH} # Unofficial: We are proposing this.
PATH_SUFFIXES lib64 lib
)
ENDIF(NOT OPENTHREADS_LIBRARY)
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +08:00
IF(NOT OPENTHREADS_LIBRARY)
Fixed tabbing
2007-04-27 17:49:28 +08:00
FIND_LIBRARY(OPENTHREADS_LIBRARY
NAMES OpenThreads OpenThreadsWin32
PATHS
~/Library/Frameworks
/Library/Frameworks
/usr/local/lib64
/usr/local/lib
/usr/lib64
/usr/lib
/sw/lib64
/sw/lib
/opt/local/lib64
/opt/local/lib
/opt/csw/lib64
/opt/csw/lib
/opt/lib64
/opt/lib
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
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ Manager\\Environment;OpenThreads_ROOT]/lib
Fixed tabbing
2007-04-27 17:49:28 +08:00
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ Manager\\Environment;OSG_ROOT]/lib
)
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +08:00
ENDIF(NOT OPENTHREADS_LIBRARY)
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
FIND_LIBRARY(OPENTHREADS_LIBRARY_DEBUG
Fixed tabbing
2007-04-27 17:49:28 +08:00
NAMES OpenThreadsd OpenThreadsWin32d
PATHS
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
$ENV{OPENTHREADS_DEBUG_LIBRARY_DIR}
Fixed tabbing
2007-04-27 17:49:28 +08:00
$ENV{OPENTHREADS_LIBRARY_DIR}
$ENV{OPENTHREADS_DIR}/lib64
$ENV{OPENTHREADS_DIR}/lib
$ENV{OPENTHREADS_DIR}
$ENV{OSG_LIBRARY_DIR}
$ENV{OSG_DIR}/lib64
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
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
${CMAKE_PREFIX_PATH}/lib64
${CMAKE_PREFIX_PATH}/lib
${CMAKE_PREFIX_PATH}
Fixed tabbing
2007-04-27 17:49:28 +08:00
NO_DEFAULT_PATH
From Eric Wing and others, first cut of CMake build support
2007-03-04 21:05:33 +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(NOT OPENTHREADS_LIBRARY_DEBUG)
FIND_LIBRARY(OPENTHREADS_LIBRARY_DEBUG
NAMES OpenThreadsd OpenThreadsWin32d
PATHS ${CMAKE_PREFIX_PATH} # Unofficial: We are proposing this.
PATH_SUFFIXES lib64 lib
)
ENDIF(NOT OPENTHREADS_LIBRARY_DEBUG)
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +08:00
IF(NOT OPENTHREADS_LIBRARY_DEBUG)
Fixed tabbing
2007-04-27 17:49:28 +08:00
FIND_LIBRARY(OPENTHREADS_LIBRARY_DEBUG
NAMES OpenThreadsd OpenThreadsWin32d
PATHS
/usr/local/lib64
/usr/local/lib
/usr/lib64
/usr/lib
/sw/lib64
/sw/lib
/opt/local/lib64
/opt/local/lib
/opt/csw/lib64
/opt/csw/lib
/opt/lib64
/opt/lib
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
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ Manager\\Environment;OpenThreads_ROOT]/lib
Fixed tabbing
2007-04-27 17:49:28 +08:00
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\ Manager\\Environment;OSG_ROOT]/lib
)
From Eric Wing, "These enhancements make it much easier to control which libraries get found by FIND_ using environmental variables. The problem with the old script was that CMake searches what it considers system paths first. This makes it difficult to override in the case where you might have a stable version in /usr/local, but are trying to build a bleeding edge release in the non-standard location /bleeding-edge. I went to the CMake mailing list hoping to find a good solution to this. Unfortunately, there isn't one, and I have to do something rather bone-headed in the Find module. Basically, I have to run FIND_ twice: once with default search paths turned off and my environmental variables listed, and again with standard search paths reenabled. At least it works. I also added a few more environmental variables, specifically: OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR These two variables address the shortcoming of OPENTHREADS_DIR in the case where the include path and library path don't share a common parent. Put all this together, and you can setup an automated shell script or Microsoft .bat file to configure and build your application in an automated step. You still should be able to use the key CMake variables like CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to find things, but it will occur after the environmental paths are searched. The reason for this is that the OPENTHREADS_INCLUDE_DIR and OPENTHREADS_LIBRARY_DIR are more specific. This prevents the accidental ordering problem where you might use CMAKE_INCLUDE_PATH to find some other component like GLUT, but didn't want to accidentally include an older version of OpenThreads located in the same area. As the ultimate override, you can still pass -DVAR=value arguments to cmake and it will take these above all else. However, it's safer for people to not use these in case we modify the script and change the variable names. Finally, I'm wondering if we can kill the ${CMAKE_INSTALL_PREFIX} searches in the Find module. As I've said before, this is kind of a hack and the variable wasn't really intended to be used in this way. And I just got bitten by it in some bad corner cases. The problem is that if you don't explicitly set the ${CMAKE_INSTALL_PREFIX}, CMake sets a default value for it (such as /usr/local). The problem is that /usr/local may not be the place you want searched. If you wait to set the ${CMAKE_INSTALL_PREFIX} in the ccmake GUI, then FIND_ is already run once on ${CMAKE_INSTALL_PREFIX=/usr/local. If you were planning to change the value in the GUI, it's too late if you had a stuff in /usr/local because FIND_ already found something and won't change the value when you reconfigure since it is already set. You will have to manually change the value yourself. Furthermore, as another problem example, on the Mac, /Library/Frameworks is supposed to be searched before /usr/local, but ${CMAKE_INSTALL_PREFIX} kept causing stuff in /usr/local to be hit first which took me a really long time to understand how this was happenning. The work around is that I must push the ${CMAKE_INSTALL_PREFIX} search to the very end as not to conflict with anything else. But I think it would be much better if we removed it entirely. And with so many different environmental variables at our disposal, I don't think we need this one: (Checked by CMake automatically:) CMAKE_INCLUDE_PATH CMAKE_SYSTEM_INCLUDE_PATH CMAKE_LIBRARY_PATH CMAKE_SYSTEM_LIBRARY_PATH PATH LIB (Checked by us:) OPENTHREADS_INCLUDE_DIR OPENTHREADS_LIBRARY_DIR OPENTHREADS_DIR OSG_INCLUDE_DIR OSG_LIBRARY_DIR OSG_DIR "
2007-04-25 17:21:57 +08:00
ENDIF(NOT OPENTHREADS_LIBRARY_DEBUG)
From Eric Wing, "Adding back missing search paths in FindOpenThreads.cmake. Also fixed a bug regarding when to set the debug version. It waited until both include and library were set, but it shouldn't wait on include. Also added a fix to the optional warning flags."
2007-04-12 18:06:09 +08:00
IF(OPENTHREADS_LIBRARY)
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
IF(NOT OPENTHREADS_LIBRARY_DEBUG)
Fixed tabbing
2007-04-27 17:49:28 +08:00
#MESSAGE("-- Warning Debug OpenThreads not found, using: ${OPENTHREADS_LIBRARY}")
#SET(OPENTHREADS_LIBRARY_DEBUG "${OPENTHREADS_LIBRARY}")
SET(OPENTHREADS_LIBRARY_DEBUG "${OPENTHREADS_LIBRARY}" CACHE FILEPATH "Debug version of OpenThreads Library (use regular version if not available)" FORCE)
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
ENDIF(NOT OPENTHREADS_LIBRARY_DEBUG)
From Eric Wing, "Adding back missing search paths in FindOpenThreads.cmake. Also fixed a bug regarding when to set the debug version. It waited until both include and library were set, but it shouldn't wait on include. Also added a fix to the optional warning flags."
2007-04-12 18:06:09 +08:00
ENDIF(OPENTHREADS_LIBRARY)
Fixed tabbing
2007-04-27 17:49:28 +08:00
From Eric Wing, "Adding back missing search paths in FindOpenThreads.cmake. Also fixed a bug regarding when to set the debug version. It waited until both include and library were set, but it shouldn't wait on include. Also added a fix to the optional warning flags."
2007-04-12 18:06:09 +08:00
SET(OPENTHREADS_FOUND "NO")
IF(OPENTHREADS_INCLUDE_DIR AND OPENTHREADS_LIBRARY)
SET(OPENTHREADS_FOUND "YES")
# MESSAGE("-- Found OpenThreads: "${OPENTHREADS_LIBRARY})
From Eric Wing and others, first cut of CMake build support
2007-03-04 21:05:33 +08:00
ENDIF(OPENTHREADS_INCLUDE_DIR AND OPENTHREADS_LIBRARY)
Reference in New Issue Copy Permalink