reactos/CMake
1
0
Fork 0
mirror of https://github.com/reactos/CMake.git synced 2024-11-23 11:39:48 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
c587b8d026
CMake/Modules/FindPythonInterp.cmake

172 lines
7.1 KiB
CMake
Raw Normal View History

Simplify CMake per-source license notices Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
2016-09-27 19:01:08 +00:00
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
# file Copyright.txt or https://cmake.org/licensing for details.
Help: Convert remaining modules to block-style comments
2018-10-22 14:31:08 +00:00
#[=======================================================================[.rst:
FindPythonInterp
----------------
.. deprecated:: 3.12
Use :module:`FindPython3`, :module:`FindPython2` or :module:`FindPython` instead.
Help: Use 'deprecated' template, and date deprecation of modules
2018-10-25 10:23:33 +00:00
Find python interpreter
Help: Convert remaining modules to block-style comments
2018-10-22 14:31:08 +00:00
This module finds if Python interpreter is installed and determines
where the executables are. This code sets the following variables:
::
PYTHONINTERP_FOUND - Was the Python executable found
PYTHON_EXECUTABLE - path to the Python interpreter
::
PYTHON_VERSION_STRING - Python version found e.g. 2.5.2
PYTHON_VERSION_MAJOR - Python major version found e.g. 2
PYTHON_VERSION_MINOR - Python minor version found e.g. 5
PYTHON_VERSION_PATCH - Python patch version found e.g. 2
The Python_ADDITIONAL_VERSIONS variable can be used to specify a list
of version numbers that should be taken into account when searching
for Python. You need to set this variable before calling
find_package(PythonInterp).
If calling both ``find_package(PythonInterp)`` and
``find_package(PythonLibs)``, call ``find_package(PythonInterp)`` first to
get the currently active Python version by default with a consistent version
of PYTHON_LIBRARIES.
FindPythonInterp: Document lack of version filtering for plain `python` Also drop the `CMakeOnly.MajorVersionSelection-PythonInterp_2` test because some environments now have a plain `python` executable for Python 3. Fixes: #19536
2019-07-30 16:07:37 +00:00
.. note::
A call to ``find_package(PythonInterp ${V})`` for python version ``V``
may find a ``python`` executable with no version suffix. In this case
no attempt is made to avoid python executables from other versions.
Use :module:`FindPython3`, :module:`FindPython2` or :module:`FindPython`
instead.
Help: Convert remaining modules to block-style comments
2018-10-22 14:31:08 +00:00
#]=======================================================================]
ENH: Initial import
2005-07-15 12:36:33 +00:00
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
unset(_Python_NAMES)
set(_PYTHON1_VERSIONS 1.6 1.5)
set(_PYTHON2_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0)
FindPython: Add support for version 3.9 Development versions of Python 3.9.0 are already out there. See PEP 596 -- Python 3.9 Release Schedule: https://www.python.org/dev/peps/pep-0596/
2020-01-14 18:41:29 +00:00
set(_PYTHON3_VERSIONS 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0)
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
if(PythonInterp_FIND_VERSION)
FindPython*: simplify version selection CMake already provides the version components split into variables, no need to split them again.
2013-08-31 15:46:44 +00:00
if(PythonInterp_FIND_VERSION_COUNT GREATER 1)
set(_PYTHON_FIND_MAJ_MIN "${PythonInterp_FIND_VERSION_MAJOR}.${PythonInterp_FIND_VERSION_MINOR}")
list(APPEND _Python_NAMES
python${_PYTHON_FIND_MAJ_MIN}
python${PythonInterp_FIND_VERSION_MAJOR})
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
unset(_PYTHON_FIND_OTHER_VERSIONS)
if(NOT PythonInterp_FIND_VERSION_EXACT)
FindPython*: simplify version selection CMake already provides the version components split into variables, no need to split them again.
2013-08-31 15:46:44 +00:00
foreach(_PYTHON_V ${_PYTHON${PythonInterp_FIND_VERSION_MAJOR}_VERSIONS})
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
if(NOT _PYTHON_V VERSION_LESS _PYTHON_FIND_MAJ_MIN)
list(APPEND _PYTHON_FIND_OTHER_VERSIONS ${_PYTHON_V})
endif()
endforeach()
Remove CMake-language block-end command arguments Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
2012-08-13 17:50:14 +00:00
endif()
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
unset(_PYTHON_FIND_MAJ_MIN)
Remove CMake-language block-end command arguments Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
2012-08-13 17:50:14 +00:00
else()
FindPython*: simplify version selection CMake already provides the version components split into variables, no need to split them again.
2013-08-31 15:46:44 +00:00
list(APPEND _Python_NAMES python${PythonInterp_FIND_VERSION_MAJOR})
set(_PYTHON_FIND_OTHER_VERSIONS ${_PYTHON${PythonInterp_FIND_VERSION_MAJOR}_VERSIONS})
Remove CMake-language block-end command arguments Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
2012-08-13 17:50:14 +00:00
endif()
else()
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
set(_PYTHON_FIND_OTHER_VERSIONS ${_PYTHON3_VERSIONS} ${_PYTHON2_VERSIONS} ${_PYTHON1_VERSIONS})
Remove CMake-language block-end command arguments Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
2012-08-13 17:50:14 +00:00
endif()
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
find_program(PYTHON_EXECUTABLE NAMES ${_Python_NAMES})
Search for the installed python interpreter first The old approach to determine the python executeable chooses the newest version from _Python_VERSIONS if no additonal versions are passed. With python it is possible to install different versions side-by-side. Therefore a user can install e.g. python 2.5 and 2.7. Python 2.7 maybe only installed for testing new features and 2.5 for building and running his software. Thus the default installation for the user would be python 2.5 and then returning PYTHON_EXECUTEABLE python2.7 would be wrong. The new approuch searches first for the the default python executable e.g. /usr/bin/python on unix and if it can't be found _Python_VERSIONS is used.
2011-07-14 09:16:00 +00:00
Python additional version support, bug #10279. Introduced an additional variable, Python_ADDITIONAL_VERSIONS, to both FindPythonLibs and FindPythonInterp. Changed FindPythonInterp to loop over versions rather than hardcoding all versions (more like libs).
2011-01-10 18:44:45 +00:00
# Set up the versions we know about, in the order we will search. Always add
# the user supplied additional versions to the front.
FindPythonInterp: Use consistent version with PythonLibs (#13794) If find_package(PythonLibs) find_package(PythonInterp) is called, help PythonInterp to get a version of PYTHON_EXECUTABLE consistent with the library versions found by PythonLibs.
2014-03-05 22:01:26 +00:00
set(_Python_VERSIONS ${Python_ADDITIONAL_VERSIONS})
# If FindPythonInterp has already found the major and minor version,
# insert that version next to get consistent versions of the interpreter and
# library.
if(DEFINED PYTHONLIBS_VERSION_STRING)
string(REPLACE "." ";" _PYTHONLIBS_VERSION "${PYTHONLIBS_VERSION_STRING}")
list(GET _PYTHONLIBS_VERSION 0 _PYTHONLIBS_VERSION_MAJOR)
list(GET _PYTHONLIBS_VERSION 1 _PYTHONLIBS_VERSION_MINOR)
list(APPEND _Python_VERSIONS ${_PYTHONLIBS_VERSION_MAJOR}.${_PYTHONLIBS_VERSION_MINOR})
endif()
# Search for the current active python version first
list(APPEND _Python_VERSIONS ";")
list(APPEND _Python_VERSIONS ${_PYTHON_FIND_OTHER_VERSIONS})
FindPythonInterp: make version selectable This allows the developer to tell FindPythonInterp which Python version should be searched for. This allows the right version to be chosen for a project without user assistance if there are specific requirements. This is especially useful as it is common to have major versions 2 and 3 installed in parallel, which are partly incompatible.
2012-01-17 17:25:10 +00:00
unset(_PYTHON_FIND_OTHER_VERSIONS)
unset(_PYTHON1_VERSIONS)
unset(_PYTHON2_VERSIONS)
unset(_PYTHON3_VERSIONS)
Python additional version support, bug #10279. Introduced an additional variable, Python_ADDITIONAL_VERSIONS, to both FindPythonLibs and FindPythonInterp. Changed FindPythonInterp to loop over versions rather than hardcoding all versions (more like libs).
2011-01-10 18:44:45 +00:00
Update documentation of FindPythonInterp.cmake Document new variables and update also comments in cmake code to explain the current behaviour of FindPythonInterp.cmake module
2011-08-05 07:53:39 +00:00
# Search for newest python version if python executable isn't found
Python additional version support, bug #10279. Introduced an additional variable, Python_ADDITIONAL_VERSIONS, to both FindPythonLibs and FindPythonInterp. Changed FindPythonInterp to loop over versions rather than hardcoding all versions (more like libs).
2011-01-10 18:44:45 +00:00
if(NOT PYTHON_EXECUTABLE)
FindPythonInterp: Use consistent version with PythonLibs (#13794) If find_package(PythonLibs) find_package(PythonInterp) is called, help PythonInterp to get a version of PYTHON_EXECUTABLE consistent with the library versions found by PythonLibs.
2014-03-05 22:01:26 +00:00
foreach(_CURRENT_VERSION IN LISTS _Python_VERSIONS)
Search for the installed python interpreter first The old approach to determine the python executeable chooses the newest version from _Python_VERSIONS if no additonal versions are passed. With python it is possible to install different versions side-by-side. Therefore a user can install e.g. python 2.5 and 2.7. Python 2.7 maybe only installed for testing new features and 2.5 for building and running his software. Thus the default installation for the user would be python 2.5 and then returning PYTHON_EXECUTEABLE python2.7 would be wrong. The new approuch searches first for the the default python executable e.g. /usr/bin/python on unix and if it can't be found _Python_VERSIONS is used.
2011-07-14 09:16:00 +00:00
set(_Python_NAMES python${_CURRENT_VERSION})
FindPythonInterp: Add `-32` and `-64` registry entry variants As of 3.6.1 Python (only version tested in this case), installing 32-bit version on 64-bit windows has a slightly different registry key path. `-32` is appended to the end of the version number in the path. Also added a few more registry path guesses based on 64-bit version of Python. Also the module now checks if the host is WIN32 instead of the target, which is required if you are cross compiling.
2017-04-07 15:31:12 +00:00
if(CMAKE_HOST_WIN32)
Search for the installed python interpreter first The old approach to determine the python executeable chooses the newest version from _Python_VERSIONS if no additonal versions are passed. With python it is possible to install different versions side-by-side. Therefore a user can install e.g. python 2.5 and 2.7. Python 2.7 maybe only installed for testing new features and 2.5 for building and running his software. Thus the default installation for the user would be python 2.5 and then returning PYTHON_EXECUTEABLE python2.7 would be wrong. The new approuch searches first for the the default python executable e.g. /usr/bin/python on unix and if it can't be found _Python_VERSIONS is used.
2011-07-14 09:16:00 +00:00
list(APPEND _Python_NAMES python)
endif()
find_program(PYTHON_EXECUTABLE
NAMES ${_Python_NAMES}
FindPythonInterp: Add `-32` and `-64` registry entry variants As of 3.6.1 Python (only version tested in this case), installing 32-bit version on 64-bit windows has a slightly different registry key path. `-32` is appended to the end of the version number in the path. Also added a few more registry path guesses based on 64-bit version of Python. Also the module now checks if the host is WIN32 instead of the target, which is required if you are cross compiling.
2017-04-07 15:31:12 +00:00
PATHS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}-32\\InstallPath]
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}-64\\InstallPath]
FindPythonInterp: support single-user installs on Windows CMake currently searches in HKEY_LOCAL_MACHINE. According to PEP 514, single-user installs are registered in HKEY_CURRENT_USER See also FindPythonLibs.cmake
2018-01-19 11:13:03 +00:00
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}-32\\InstallPath]
[HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}-64\\InstallPath]
Search for the installed python interpreter first The old approach to determine the python executeable chooses the newest version from _Python_VERSIONS if no additonal versions are passed. With python it is possible to install different versions side-by-side. Therefore a user can install e.g. python 2.5 and 2.7. Python 2.7 maybe only installed for testing new features and 2.5 for building and running his software. Thus the default installation for the user would be python 2.5 and then returning PYTHON_EXECUTEABLE python2.7 would be wrong. The new approuch searches first for the the default python executable e.g. /usr/bin/python on unix and if it can't be found _Python_VERSIONS is used.
2011-07-14 09:16:00 +00:00
)
endforeach()
Python additional version support, bug #10279. Introduced an additional variable, Python_ADDITIONAL_VERSIONS, to both FindPythonLibs and FindPythonInterp. Changed FindPythonInterp to loop over versions rather than hardcoding all versions (more like libs).
2011-01-10 18:44:45 +00:00
endif()
Update documentation of FindPythonInterp.cmake Document new variables and update also comments in cmake code to explain the current behaviour of FindPythonInterp.cmake module
2011-08-05 07:53:39 +00:00
# determine python version string
Determine python version Use PYTHON_EXECUTABLE to determine PYTHON_VERSION_STRING, PYTHON_VERSION_MINOR, PYTHON_VERSION_MAJOR and PYTHON_VERSION_PATCH
2011-07-14 09:43:47 +00:00
if(PYTHON_EXECUTABLE)
FindPythonInterp: rework the version detection There are versions out there that neither understand --version nor -V. Try a completely different approach: execute a small python script that prints the version number (and only that) in an easily reusable way using sys.version_info. This is documented to work since Python 2.0. Use sys.version for older versions, which is documented to exist since 1.5. If even that doesn't work then simply assume we are on 1.4.0.
2012-02-26 08:29:02 +00:00
execute_process(COMMAND "${PYTHON_EXECUTABLE}" -c
"import sys; sys.stdout.write(';'.join([str(x) for x in sys.version_info[:3]]))"
OUTPUT_VARIABLE _VERSION
FindPythonInterp: try harder to get a version number
2012-01-27 20:15:53 +00:00
RESULT_VARIABLE _PYTHON_VERSION_RESULT
FindPythonInterp: rework the version detection There are versions out there that neither understand --version nor -V. Try a completely different approach: execute a small python script that prints the version number (and only that) in an easily reusable way using sys.version_info. This is documented to work since Python 2.0. Use sys.version for older versions, which is documented to exist since 1.5. If even that doesn't work then simply assume we are on 1.4.0.
2012-02-26 08:29:02 +00:00
ERROR_QUIET)
if(NOT _PYTHON_VERSION_RESULT)
string(REPLACE ";" "." PYTHON_VERSION_STRING "${_VERSION}")
list(GET _VERSION 0 PYTHON_VERSION_MAJOR)
list(GET _VERSION 1 PYTHON_VERSION_MINOR)
list(GET _VERSION 2 PYTHON_VERSION_PATCH)
if(PYTHON_VERSION_PATCH EQUAL 0)
# it's called "Python 2.7", not "2.7.0"
string(REGEX REPLACE "\\.0$" "" PYTHON_VERSION_STRING "${PYTHON_VERSION_STRING}")
endif()
else()
# sys.version predates sys.version_info, so use that
FindPythonInterp: Do not assume any version if test script fails The Python version is retrieved by executing a small python script. If, for any reason, script fails to execute, leave the `PYTHON_VERSION_*` variables undefined instead of assuming version 1.4. Fixes: #18799
2019-01-21 15:41:59 +00:00
# sys.version was first documented for Python 1.5, so assume version 1.4
# if retrieving sys.version fails.
execute_process(COMMAND "${PYTHON_EXECUTABLE}" -c "try: import sys; sys.stdout.write(sys.version)\nexcept: sys.stdout.write(\"1.4.0\")"
FindPythonInterp: rework the version detection There are versions out there that neither understand --version nor -V. Try a completely different approach: execute a small python script that prints the version number (and only that) in an easily reusable way using sys.version_info. This is documented to work since Python 2.0. Use sys.version for older versions, which is documented to exist since 1.5. If even that doesn't work then simply assume we are on 1.4.0.
2012-02-26 08:29:02 +00:00
OUTPUT_VARIABLE _VERSION
FindPythonInterp: try harder to get a version number
2012-01-27 20:15:53 +00:00
RESULT_VARIABLE _PYTHON_VERSION_RESULT
FindPythonInterp: rework the version detection There are versions out there that neither understand --version nor -V. Try a completely different approach: execute a small python script that prints the version number (and only that) in an easily reusable way using sys.version_info. This is documented to work since Python 2.0. Use sys.version for older versions, which is documented to exist since 1.5. If even that doesn't work then simply assume we are on 1.4.0.
2012-02-26 08:29:02 +00:00
ERROR_QUIET)
if(NOT _PYTHON_VERSION_RESULT)
string(REGEX REPLACE " .*" "" PYTHON_VERSION_STRING "${_VERSION}")
string(REGEX REPLACE "^([0-9]+)\\.[0-9]+.*" "\\1" PYTHON_VERSION_MAJOR "${PYTHON_VERSION_STRING}")
string(REGEX REPLACE "^[0-9]+\\.([0-9])+.*" "\\1" PYTHON_VERSION_MINOR "${PYTHON_VERSION_STRING}")
Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex) The matches have already been calculated and can simply be taken from CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very similar regular expressions.
2014-04-06 19:30:00 +00:00
if(PYTHON_VERSION_STRING MATCHES "^[0-9]+\\.[0-9]+\\.([0-9]+)")
set(PYTHON_VERSION_PATCH "${CMAKE_MATCH_1}")
FindPythonInterp: rework the version detection There are versions out there that neither understand --version nor -V. Try a completely different approach: execute a small python script that prints the version number (and only that) in an easily reusable way using sys.version_info. This is documented to work since Python 2.0. Use sys.version for older versions, which is documented to exist since 1.5. If even that doesn't work then simply assume we are on 1.4.0.
2012-02-26 08:29:02 +00:00
else()
set(PYTHON_VERSION_PATCH "0")
endif()
else()
FindPythonInterp: Do not assume any version if test script fails The Python version is retrieved by executing a small python script. If, for any reason, script fails to execute, leave the `PYTHON_VERSION_*` variables undefined instead of assuming version 1.4. Fixes: #18799
2019-01-21 15:41:59 +00:00
unset(PYTHON_VERSION_STRING)
unset(PYTHON_VERSION_MAJOR)
unset(PYTHON_VERSION_MINOR)
unset(PYTHON_VERSION_PATCH)
FindPythonInterp: fix version parsing On dashmacmini2 the test showed output like this: -- Found PythonInterp: /usr/bin/python (found version "Unknown option: -- usage: /usr/bin/python [option] ... [-c cmd | file | -] [arg] ... Try `python -h' for more information.") On my machine where python outputs "Python 2.7" this worked, but PYTHON_VERSION_MAJOR, PYTHON_VERSION_MINOR, and PYTHON_VERSION_PATCH were all set to "2.7". Add some checks that the version output has the expected form before using it.
2012-01-19 22:31:38 +00:00
endif()
endif()
FindPythonInterp: try harder to get a version number
2012-01-27 20:15:53 +00:00
unset(_PYTHON_VERSION_RESULT)
unset(_VERSION)
Remove CMake-language block-end command arguments Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
2012-08-13 17:50:14 +00:00
endif()
ENH: Initial import
2005-07-15 12:36:33 +00:00
Modules: Include builtin FindPackageHandleStandardArgs directly The FindPackageHandleStandardArgs module was originally created outside of CMake. It was added for CMake 2.6.0 by commit e118a627 (add a macro FIND_PACKAGE_HANDLE_STANDARD_ARGS..., 2007-07-18). However, it also proliferated into a number of other projects that at the time required only CMake 2.4 and thus could not depend on CMake to provide the module. CMake's own find modules started using the module in commit b5f656e0 (use the new FIND_PACKAGE_HANDLE_STANDARD_ARGS in some of the FindXXX modules..., 2007-07-18). Then commit d358cf5c (add 2nd, more powerful mode to find_package_handle_standard_args, 2010-07-29) added a new feature to the interface of the module that was fully optional and backward compatible with all existing users of the module. Later commit 5f183caa (FindZLIB: use the FPHSA version mode, 2010-08-04) and others shortly thereafter started using the new interface in CMake's own find modules. This change was also backward compatible because it was only an implementation detail within each module. Unforutnately these changes introduced a problem for projects that still have an old copy of FindPackageHandleStandardArgs in CMAKE_MODULE_PATH. When any such project uses one of CMake's builtin find modules the line include(FindPackageHandleStandardArgs) loads the copy from the project which does not have the new interface! Then the including find module tries to use the new interface with the old module and fails. Whether this breakage can be considered a backward incompatible change in CMake is debatable. The situation is analagous to copying a standard library header from one version of a compiler into a project and then observing problems when the next version of the compiler reports errors in its other headers that depend on its new version of the original header. Nevertheless it is a change to CMake that causes problems for projects that worked with previous versions. This problem was discovered during the 2.8.3 release candidate cycle. It is an instance of a more general problem with projects that provide their own versions of CMake modules when other CMake modules depend on them. At the time we resolved this instance of the problem with commit b0118402 (Use absolute path to FindPackageHandleStandardArgs.cmake everywhere, 2010-09-28) for the 2.8.3 release. In order to address the more general problem we introduced policy CMP0017 in commit db44848f (Prefer files from CMAKE_ROOT when including from CMAKE_ROOT, 2010-11-17). That change was followed by commit ce28737c (Remove usage of CMAKE_CURRENT_LIST_DIR now that we have CMP0017, 2010-12-20) which reverted the original workaround in favor of using the policy. However, existing project releases do not set the policy behavior to NEW and therefore still exhibit the problem. We introduced in commit a364daf1 (Allow users to specify defaults for unset policies, 2011-01-03) an option for users to build existing projects by adding -DCMAKE_POLICY_DEFAULT_CMP0017=NEW to the command line. Unfortunately this solution still does not allow such projects to build out of the box, and there is no good way to suggest the use of the new option. The only remaining solution to keep existing projects that exhibit this problem building is to restore the change originally made in commit b0118402 (Use absolute path to FindPackageHandleStandardArgs.cmake everywhere, 2010-09-28). This also avoids policy CMP0017 warnings for this particular instance of the problem the policy addresses.
2011-01-20 15:56:49 +00:00
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
Use FIND_PACKAGE_HANDLE_STANDARD_ARGS second mode Using the second mode of FIND_PACKAGE_HANDLE_STANDARD_ARGS allows for checking the version number. Now a user can require a minimum version of the python interpreter with find_package(PythonInterp VERSION)
2011-08-23 07:36:17 +00:00
FIND_PACKAGE_HANDLE_STANDARD_ARGS(PythonInterp REQUIRED_VARS PYTHON_EXECUTABLE VERSION_VAR PYTHON_VERSION_STRING)
STYLE: mark the variable as advanced Alex
2007-07-23 15:22:14 +00:00
Python additional version support, bug #10279. Introduced an additional variable, Python_ADDITIONAL_VERSIONS, to both FindPythonLibs and FindPythonInterp. Changed FindPythonInterp to loop over versions rather than hardcoding all versions (more like libs).
2011-01-10 18:44:45 +00:00
mark_as_advanced(PYTHON_EXECUTABLE)
Reference in New Issue Copy Permalink