summaryrefslogtreecommitdiffstats
path: root/Modules/FindPythonLibs.cmake
Commit message (Collapse)AuthorAgeFilesLines
* FindPython: Add support for Python 3.11Tomáš Hrnčiar2021-12-071-1/+1
|
* FindPython{Interp,Libs}: Add support for version 3.10Miro Hrončok2020-11-091-1/+1
| | | | | | Extend the change from commit 23cd98a66a (FindPython: Add support of version 3.10, 2020-10-16, v3.19.0-rc2~25^2) to cover the legacy `FindPython{Interp,Libs}` modules too.
* FindPython: Add support for version 3.9Miro Hrončok2020-01-141-1/+1
| | | | | | | 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/
* Help: Use 'deprecated' template, and date deprecation of modulesJoachim Wuttke (o)2018-10-251-2/+2
|
* Help: Convert remaining modules to block-style commentsKitware Robot2018-10-221-42/+43
|
* FindPython*: Add missing registry pathsMarc Chevrier2018-10-111-0/+44
| | | | Fixes: #18443
* FindPython: Add support for version 3.8Marcel Plch2018-06-081-1/+1
| | | | Python 3.7 is about to be released, making the development version 3.8.
* FindPython*: New implementation for Python stuffMarc Chevrier2018-03-201-0/+4
| | | | Fixes: #16142
* FindPythonLibs: Allow find_library to search paths from system environmentBrad King2017-10-111-4/+0
| | | | | | | | | | Drop the `NO_SYSTEM_ENVIRONMENT_PATH` option from our `find_library` calls. No other find modules do this. Also, since commit v3.3.0-rc1~430^2 (Teach find_(library|file|path) to get prefixes from PATH, 2015-02-18) we always search the `lib` directory of each prefix before the `bin` directory and so should prefer the non-`.dll` name. Issue: #17336
* FindPythonLibs: Prefer libs early in search path regardless of nameBrad King2017-10-111-0/+3
| | | | | | | | | Add `NAMES_PER_DIR` to all `find_library` invocations so that we consider all possible names in each search directory before moving on to the next directory. This helps find the package that appears earliest in the search path regardless of how it names its libraries. Fixes: #17336
* FindPythonLibs: Tolerate call with PYTHON_LIBRARY already a listFrancois Budin2016-12-151-6/+13
| | | | | | | | | | | | | | `PYTHON_LIBRARY` may contain a list because of `SelectLibraryConfigurations`. If it is the case, the list can be: optimized;<FILEPATH_TO_RELEASE_LIBRARY>;debug;<FILEPATH_TO_DEBUG_LIBRARY> Instead of directly using the value of `PYTHON_LIBRARY` in the CMake function `get_filename_component()`, we loop over the content of the relevant parts of `PYTHON_LIBRARY` and `PYTHON_DEBUG_LIBRARY` whether they are lists or not. Suggested-by: Brad King <brad.king@kitware.com>
* FindPythonLibs: Tolerate a non-absolute PYTHON_EXECUTABLEBrad King2016-11-281-4/+4
| | | | | | | | The `PYTHON_EXECUTABLE` variable normally contains an absolute path, but tolerate cases when it does not without calling `get_filename_component` with an incorrect number of arguments. Closes: #16452
* Simplify CMake per-source license noticesBrad King2016-09-271-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* FindPython{Interp,Libs}: Add version 3.7Yen Chi Hsuan2016-09-141-1/+1
|
* FindPython{Interp,Libs}: Clarify recommended call orderBrad King2016-03-071-3/+4
| | | | Improve wording in our advice about how to call both of these modules.
* FindPythonLibs: unset temporary _PREFIX variableDavid Gobbi2015-09-171-11/+14
| | | | To avoid pollution, unset variables that are only meant for local use.
* FindPythonLibs: Use python executable prefix as a hintDavid Gobbi2015-09-171-0/+21
| | | | | | If PYTHON_EXECUTABLE is set, then we should look for the libs in the same prefix, e.g. /usr/local/python -> /usr/local/lib, and on Win32 /Python34/python.exe -> /Python34/libs.
* FindPythonLibs: Match include dir to library versionDavid Gobbi2015-09-171-19/+36
| | | | | | This commit ensures that FindPythonLibs has found the library before before the search for the include dir begins. The library prefix and version can then be used to find the matching include dir.
* FindPythonLibs: Fix OS X framework include directory search pathDavid Gobbi2015-09-161-1/+1
| | | | | | | | We use PATH_SUFFIXES to append "python<v>" to each candidate path. Do not append it to the constructed list of python framework include directories. Otherwise the combined path will never exist. Note that the code doesn't yet try to match the suffixes "m" and "u" between the executable, library, and include directory.
* FindPythonLibs: Remove PYTHON_INCLUDE_PATH as inputDavid Gobbi2015-09-161-7/+0
| | | | | | This cmake variable has been deprecated for over a decade, and using it as an input could potentially cause unexpected results. We still need to keep it as an output variable for compatibility though.
* FindPython{Interp,Libs}: Add versions 3.5 and 3.6David Gobbi2015-09-161-1/+1
|
* FindPythonLibs: Find the python.org libraries (#14809)Matt McCormick2015-07-061-7/+32
| | | | | | | | | | | | | | | | Address the test case cmake_minimum_required(VERSION 2.8) set(Python_ADDITIONAL_VERSIONS 3.4 3.5 3.6) find_package(PythonLibs 3 REQUIRED) with a Python 3.4.x .pkg installed from python.org on OSX. Temporarily set CMAKE_FIND_FRAMEWORK to LAST to avoid finding the system Python.h prematurely. Add directories inside the frameworks to the search list for the library as is done for the header.
* Merge topic 'different-python-header-libs-exe-0013794'Brad King2014-03-141-0/+4
|\ | | | | | | | | | | 59220198 FindPython*: Document suggested find_package order (#13794) a9e6de2a FindPythonInterp: Use consistent version with PythonLibs (#13794)
| * FindPython*: Document suggested find_package order (#13794)Matt McCormick2014-03-141-0/+4
| | | | | | | | | | Document in both FindPythonInterp.cmake and FindPythonLibs.cmake that find_package(PythonInterp) should be called before find_package(PythonLibs).
* | Merge topic 'python-3.4'Brad King2014-03-071-1/+1
|\ \ | |/ |/| | | | | ab6201ab FindPython{Interp,Libs}: Search for Python 3.4.
| * FindPython{Interp,Libs}: Search for Python 3.4.Matt McCormick2014-03-061-1/+1
| | | | | | | | Python 3.4.0rnc1 was released on 2014-02-20.
* | FindPythonLibs: Do not try to find the interpreter (#13794)Brad King2014-03-051-1/+0
| | | | | | | | | | | | | | | | | | | | The parent commit taught FindPythonLibs to try to find PythonInterp unconditionally. Some projects may want the libraries of a specific version even when the corresponding interpreter is not available. Drop the internal use of FindPythonInterp and just use the versions from it if it happens to have been found by the project first. That will allow projects to get a consistent version when they want both but not otherwise force them to find the interpreter.
* | FindPythonLibs: Find consistent Python interp, headers, libs (#13794)Matt McCormick2014-03-031-4/+9
|/ | | | | | | | | | | | | | When possible, get consistent version of the Python interpreter, headers path, and library. Now find_package(PythonLibs) internally calls find_package(PythonInterp QUIET) and uses the resulting PYTHON_VERSION_MAJOR and PYTHON_VERSION_MINOR to prefer these versions when looking for the header path and library. The Python_ADDITIONAL_VERSIONS variable has priority over the interpreter version. Co-Author: Adam Wolf Co-Author: Gert Wollny <gw.fossdev@gmail.com>
* Convert builtin help to reStructuredText source filesKitware Robot2013-10-151-16/+29
| | | | | | | | Run the convert-help.bash script to convert documentation: ./convert-help.bash "/path/to/CMake-build/bin" Then remove it.
* FindPython*: simplify version selectionRolf Eike Beer2013-08-311-6/+4
| | | | | CMake already provides the version components split into variables, no need to split them again.
* Find* (and some other): use ${CMAKE_CURRENT_LIST_DIR} in include()Rolf Eike Beer2012-11-041-1/+1
| | | | | | This solves a lots of warnings, e.g. in the FindModulesExecuteAll test. If the installed version on the system is rather old this may even lead to bugs, e.g. https://bugs.gentoo.org/show_bug.cgi?id=436540
* Remove CMake-language block-end command argumentsKitware Robot2012-08-131-25/+25
| | | | | | | | | | | | | | | | | 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
* Convert CMake-language commands to lower caseKitware Robot2012-08-131-119/+119
| | | | | | | | | | | | | | | | | Ancient CMake versions required upper-case commands. Later command names became case-insensitive. Now the preferred style is lower-case. Run the following shell code: cmake --help-command-list | grep -v "cmake version" | while read c; do echo 's/\b'"$(echo $c | tr '[:lower:]' '[:upper:]')"'\(\s*\)(/'"$c"'\1(/g' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | xargs -0 sed -i -f convert.sed && rm convert.sed
* FindPythonLibs: honor EXACT version specification (#13216)Rolf Eike Beer2012-06-051-2/+8
|
* FindPythonLibs: Document cache variables (#13240)Zack Galbreath2012-05-221-0/+5
| | | | | Add information on how to change which install of Python is found by CMake.
* Search for other ABIFLAGS builds of PythonBen Boeckel2012-03-271-1/+9
| | | | | | | | | | | | | | | | | Starting with Python3, standard Python installs may have additional ABI flags attached to include directories and library names. As of 3.2, the following flags are in the configure file: d -> --with-debug m -> --with-pymalloc u -> --with-wide-unicode Python 3.3 seems to no longer have --with-wide-unicode. Hopefully Python will ensure that the possible flags always show up in a stable order. The 'd' flag is ignored since the debug library is considered separate. There is still the problem where ABI flags cannot be specified in find_package since the letters confuse the version comparator.
* Don't put legacy variables back into the cacheBen Boeckel2012-03-271-3/+2
| | | | | | | | | | | | | | | If PYTHON_INCLUDE_PATH is put into the cache, then it will always override whatever might be found and PYTHON_INCLUDE_DIR is never given a chance to find something different. It being marked as INTERNAL also means that it cannot be changed without editing CMakeCache.txt directly. Basically, the scenario is that if the Python version is changed, then deleting PYTHON_INCLUDE_DIR doesn't work because any cached PYTHON_INCLUDE_PATH variable is set before find_path is even called. Any build tree using a previous version will still need either manual removal of PYTHON_INCLUDE_PATH or a complete reconfigure, but in the future changing the Python version can be accomplished by deleting PYTHON_INCLUDE_DIR and reconfiguring with the new version.
* FindPythonLibs: stop scanning when libraries are foundRolf Eike Beer2012-02-231-0/+4
|
* FindPythonLibs: put debug libraries into PYTHON_LIBRARIESRolf Eike Beer2012-02-231-3/+11
|
* FindPythonLibs: get the exact version of the found library (#3080)Rolf Eike Beer2012-02-221-2/+12
|
* FindPythonLibs: make the version selection work as for PythonInterpRolf Eike Beer2012-02-221-2/+33
|
* FindPython{Interp,Libs}: document Python_ADDITIONAL_VERSIONS as inputRolf Eike Beer2012-02-221-1/+4
| | | | | The current documentation could be read as if that variable is output from the module, which is nonsense.
* FindPythonLibs: Search for single-user installs on WindowsChristian Andersson2012-01-101-1/+6
| | | | | | | | | | | | | When cmake searches for Python libs in Windows it searches in: [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs However, the information might not always reside there. The information could also reside in: [HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs when one installs Python for a single user and not for all users.
* Modules: Include builtin FindPackageHandleStandardArgs directlyBrad King2011-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge topic 'python-modules-header'Brad King2011-01-191-0/+1
|\ | | | | | | | | 23635ff Bug #11715 - generate header in the build tree.
| * Bug #11715 - generate header in the build tree.Marcus D. Hanwell2011-01-171-0/+1
| | | | | | | | | | | | The module header was being placed in the source tree before. Thanks to Marcel Loose for the patch, this ensures the file is written to the build tree.
* | Merge branch 'policy-CMP0017' into resolve/python-versions/policy-CMP0017Brad King2011-01-111-1/+1
|\ \ | |/ |/| | | | | Conflicts: Modules/FindPythonInterp.cmake
| * Remove usage of CMAKE_CURRENT_LIST_DIR now that we have CMP0017Alex Neundorf2011-01-041-1/+1
| | | | | | | | | | | | | | | | This puts the new search behaviour for included files in action, i.e. now when a file from Modules/ include()s another file, it also gets the one from Modules/ included, i.e. the one it expects. Alex
* | Python additional version support, bug #10279.Marcus D. Hanwell2011-01-101-14/+20
|/ | | | | | 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).
* Merge topic 'PythonLibs-2.7'David Cole2010-10-281-1/+1
|\ | | | | | | | | 1f369a7 ENH: Added case for Python 2.7.
generated by cgit v0.12 at 2024-11-14 10:57:59 (GMT)