summaryrefslogtreecommitdiffstats
path: root/Modules/FindPythonLibs.cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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.
| * ENH: Added case for Python 2.7.Marcus D. Hanwell2010-10-191-1/+1
| |
* | Use absolute path to FindPackageHandleStandardArgs.cmake everywhereAlex Neundorf2010-09-281-1/+1
|/ | | | | | | This is to avoid getting an (older) copy of FPHSA.cmake which is e.g. installed with KDE 4.5.0 and 4.5.1. Alex
* Set the module prefix, updated Windows suffix.David Gobbi2010-09-241-0/+7
| | | | | Set the Python module prefix to PYTHON_MODULE_PREFIX, and changed the suffix on Windows to .pyd as .dll is officially deprecated.
* Bug with default library type of Python modules.Marcus D. Hanwell2010-08-131-4/+2
| | | | | | The _TARGET_SUPPORTS_SHARED_LIBS variable was being altered outside of the find module, moving it into the function fixes any of these scoping issues. Fix tested and verified in VTK and Titan.
* Modules: Fix spelling 'To distributed' -> 'To distribute'Todd Gamblin2010-08-091-1/+1
|
* A few small changed from Pat Marion (in VTK CVS too)Marcus Hanwell2010-02-171-2/+2
|
* Applied patch from Pat Marion - modules header macro.Marcus Hanwell2010-02-171-6/+12
| | | | | | This modifies the behavior of PYTHON_WRITE_MODULES_HEADER, should be backwards compatible. Also marked a couple of the variables generated by adding Python modules as advanced.
* Do not force frameworks on Mac OS X - never worked well.Marcus Hanwell2010-02-171-16/+0
|
* Added a second call to find_library to find the static library.Marcus Hanwell2009-12-141-0/+8
| | | | | | When there is no shared object to link to a second call to find library is necessary to find the static Python library. Fixes an issue raised on the CMake mailing list, and it should be included in the next CMake patch release.
* Fixed bug 8319, search for the Python shared library in the standard locations.Marcus Hanwell2009-10-191-2/+0
|
* Convert CMake find-modules to BSD LicenseBrad King2009-09-281-0/+13
| | | | | | | This adds copyright/license notification blocks CMake's find-modules. Many of the modules had no notices at all. Some had notices referring to the BSD license already. This commit normalizes existing notices and adds missing notices.
* Change FindPythonLibs to use the standard _DIR instead of _PATH but stay ↵Bill Hoffman2009-09-141-14/+27
| | | | backwards compatible
* STYLE: use global property instead of helper target to collect all pythonAlexander Neundorf2008-02-151-12/+13
| | | | | | modules from a source tree Alex
* ENH: Changed signature of GET_PROPERTY command to be more powerful and ↵Brad King2008-01-171-1/+2
| | | | extendible.
* BUG: make the string static, otherwise the contents are gone when we exitAlexander Neundorf2007-09-181-1/+1
| | | | | | the function (same fix as in VTK/CMake/) Alex
* ENH: add support for the next python release, python 2.6Alexander Neundorf2007-08-301-1/+1
| | | | Alex
* STYLE: this wasn't intended to be committedAlexander Neundorf2007-08-161-1/+0
| | | | Alex
* ENH: add -Wl,-relax to the default linker flags for BlueGene, otherwise you ↵Alexander Neundorf2007-08-161-0/+1
| | | | | | can get "relocation truncated to fit" errors Alex
* ENH: make the python modules usable for C and C++ and only write the headerAlexander Neundorf2007-08-021-9/+31
| | | | | | if it has changed Alex
* ENH: deb generator can now generate deb packagesAlexander Neundorf2007-07-271-1/+1
| | | | | | | | | | -remove the unscriptable commands also from the cpack cmake -use CPACK_PACKAGE_CONTACT in CMakeCPack.cmake, it's used in the nsis and the deb generator -make set_properties() scriptable -use a non-const char array for adding the python modules Alex
* COMP: same as in VTK, build modules by default as shared if the platformAlexander Neundorf2007-07-251-8/+10
| | | | | | supports this, don't include shared modules in the generated header Alex
* ENH: add second failure message parameter toAlexander Neundorf2007-07-231-1/+1
| | | | | | | | FIND_PACKAGE_HANDLE_STANDARD_ARGS(), so cmake modules can specify their own better failure messages. If the default is ok use "DEFAULT_MSG". Do this also for FindBoost.cmake (#5349) Alex
* BUG: fix typoAlexander Neundorf2007-07-191-1/+1
| | | | Alex
* ENH: make the list of modules globalAlexander Neundorf2007-07-191-2/+10
| | | | Alex
* ENH: only load the static modules in the LoadAll functionAlexander Neundorf2007-07-191-3/+4
| | | | Alex
* ENH: use the new FIND_PACKAGE_HANDLE_STANDARD_ARGS() macro in most of theAlexander Neundorf2007-07-191-98/+82
| | | | | | | not-too-complicated modules -remove unnecessary default search paths used in the FIND_XXX() calls Alex
* ENH: add a macro FIND_PACKAGE_HANDLE_STANDARD_ARGS(LibXml2 LIBXML2_LIBRARIES ↵Alexander Neundorf2007-07-181-0/+5
| | | | | | | | LIBXML2_INCLUDE_DIR) which handles the required and QUIET arguments and sets <NAME>_FOUND Alex
* ENH: apply patch from Dirk Mueller to support Python 2.5Alexander Neundorf2006-09-271-3/+10
| | | | Alex
* ENH: Updated implementation to use new FIND_* command power. The correct ↵Brad King2006-03-241-41/+48
| | | | library is now found on MinGW also.
* ENH: cleanupsKen Martin2005-12-151-3/+3
|
* ENH: add documentation support for modulesBill Hoffman2005-12-141-1/+1
|
* ENH: Removing extra 64-bit search paths. They are now constructed ↵Brad King2005-04-071-3/+0
| | | | automatically from the paths listed.
* ENH: Adding support for 64-bit library paths. Contributed by Peter Vanroose.Brad King2005-04-071-0/+3
|
* ENH: bug fix 1574Bill Hoffman2005-02-101-3/+10
|
* ENH: Cleanup. Use relative path to modulesAndy Cedilnik2004-08-271-1/+1
|
* BUG#423: Fixed search for frameworks on OSX.Brad King2003-12-291-30/+27
|
* BUG: remove junk codeBill Hoffman2003-11-211-12/+0
|