Re: [CMake] FindPythonLibs on macOS

Hi Marc, > On Jun 22, 2018, at 10:32 AM, Marc CHEVRIER wrote: > > There is no specific reason. > But, starting with CMake 3.12, a new approach to manage python is available > (modules FindPython2, FindPython3 and FindPython) which take care of > consistency between interpreter and libraries an

Re: [CMake] FindPythonLibs on macOS

There is no specific reason. But, starting with CMake 3.12, a new approach to manage python is available (modules FindPython2, FindPython3 and FindPython) which take care of consistency between interpreter and libraries and rely, when possible, on python-config tool. Le ven. 22 juin 2018 à 11:04

[CMake] FindPythonLibs on macOS

Hi everyone, I'm having trouble with FindPythonLibs on macOS when having a version of Python installed from either via python.org or Homebrew (in addition to the system one). The issue is that I end up with an inconsistency between the library and the interpreter, which c

[CMake] FindPythonLibs patches for version searching and frameworks

Hi All, I've attached three suggested patches for cmake. The first is trivial, it simply adds Python 3.5 and 3.6 to the search list. The second removes the long-deprecated PYTHON_INCLUDE_PATH as a suggestion for PYTHON_INCLUDE_DIR. The third does two important things: 1) it fixes bugs for searc

[CMake] FindPythonLibs Bug #0013794 fix

Hi folks, While we're talking Python, I wrote a small patch to FindPythonLibs that looks to see if PYTHON_VERSION_MAJOR and PYTHON_VERSION_MINOR are set (by FindPythonInterp), and if so, it puts them in the python versions list, after the user specified versions, but before the Python3, Python2, a

Re: [CMake] FindPythonLibs : Version selection on OS X

On 13.01.12 15:33:23, Nicholas Yue wrote: > Hi, > > Using the FindPythonLibs macros on OS X Lion always returns the > standard Python 2.7 (shipped with Lion) > > There are other versions of Python which is also available in OS > X Lion. > > Is it possible to inform FindPythonLibs to

[CMake] FindPythonLibs : Version selection on OS X

Hi, Using the FindPythonLibs macros on OS X Lion always returns the standard Python 2.7 (shipped with Lion) There are other versions of Python which is also available in OS X Lion. Is it possible to inform FindPythonLibs to look for a different version of Python e.g. 2.6, if so

[CMake] FindPythonLibs fails inexplicably

I'm having trouble diagnosing why a call to FIND_PACKAGE(PythonLibs) is failing. I am running CMake 2.8.5 on Windows 7 Enterprise, 64-bit. The same CMake code works fine on my colleagues' systems, so it's got to be something wrong on my machine. In my CMakeLists.txt, I've got something like this:

[CMake] FindPythonLibs no longer finding Python libs in Windows 7 64 bit?

On a 64 bit Windows 7 machine, the call to find the python libraries using the FindPythonLibs.cmake module is not finding where python is installed. I tried this with both version 2.8.4 and with 2.8.5 of CMake, with Python 2.7 installed. Using the same code, FindPythonLibs works ok on my Windows

Re: [CMake] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH

On Wed, Sep 9, 2009 at 10:08 AM, Marcel Loose wrote: > On Wed, 2009-09-09 at 09:26 +0200, Marcel Loose wrote: >> On Mon, 2009-09-07 at 22:01 +0200, Alexander Neundorf wrote: >> > On Monday 07 September 2009, Marcel Loose wrote: >> > > Hi all, >> > > >> > > In fact the subject line says it all. To b

Re: [CMake] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH

On Wed, 2009-09-09 at 09:26 +0200, Marcel Loose wrote: > On Mon, 2009-09-07 at 22:01 +0200, Alexander Neundorf wrote: > > On Monday 07 September 2009, Marcel Loose wrote: > > > Hi all, > > > > > > In fact the subject line says it all. To be compliant with the naming > > > conventions proposed in th

Re: [CMake] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH

On Mon, 2009-09-07 at 22:01 +0200, Alexander Neundorf wrote: > On Monday 07 September 2009, Marcel Loose wrote: > > Hi all, > > > > In fact the subject line says it all. To be compliant with the naming > > conventions proposed in the Modules/readme.txt file, FindPythonLibs > > should set PYTHON_INC

Re: [CMake] FindPythonLibs should set PYTHON_INCLUDE _DIR instead of PYTHON_INCLUDE_PATH

On Monday 07 September 2009, Marcel Loose wrote: > Hi all, > > In fact the subject line says it all. To be compliant with the naming > conventions proposed in the Modules/readme.txt file, FindPythonLibs > should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH. > > To avoid breaking existing s

[CMake] FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH

Hi all, In fact the subject line says it all. To be compliant with the naming conventions proposed in the Modules/readme.txt file, FindPythonLibs should set PYTHON_INCLUDE_DIR instead of PYTHON_INCLUDE_PATH. To avoid breaking existing software, it would be best to simply just add a definition for

Re: [CMake] FindPythonLibs

Karl Merkley wrote: > > I'm linking an app with the python library and I have a requirement to > link with the shared library not the static library. It appears that > FindPythonLibs has no way of specifying shared vs. static. The shared > lib actually is installed in /usr/lib. The static lib

[CMake] FindPythonLibs

I'm linking an app with the python library and I have a requirement to link with the shared library not the static library. It appears that FindPythonLibs has no way of specifying shared vs. static. The shared lib actually is installed in /usr/lib. The static lib resides in /usr/lib/p

Re: [CMake] FindPythonLibs

Andreas Beckermann wrote: Hi I have a problem with FindPythonLibs on unix: if the shared version of this library is not available (but the static one is!), then dependencies of the python libraries are not resolved. I think FindPythonLibs.cmake should place the dependencies into the PYTHON_LIB

[CMake] FindPythonLibs

Hi I have a problem with FindPythonLibs on unix: if the shared version of this library is not available (but the static one is!), then dependencies of the python libraries are not resolved. I think FindPythonLibs.cmake should place the dependencies into the PYTHON_LIBRARIES variable, i.e. cmake

Re: [CMake] FindPythonLibs

At 06:35 PM 2/22/2006, James Bigler wrote: o >So it could just be how Suse sets it up, but it is troubling none the less. >Should FIND_LIBRARY search all the paths for a shared library and then go back >and look for static ones? I think what needs to be done is this: http://www.cmake.org/Bug/bu

Re: [CMake] FindPythonLibs

William A. Hoffman wrote: At 03:36 PM 2/22/2006, James Bigler wrote: CMake should prefer the shared versions of libraries. Is there a: /usr/lib/python2.4/config/libpython2.4.so on your machine? No. I'm using Suse 9.3, GCC 3.3.5, CMake 2.2-patch 3, SWIG version 1.3.21, and python 2.4. ls -l

Re: [CMake] FindPythonLibs

At 03:36 PM 2/22/2006, James Bigler wrote: >>CMake should prefer the shared versions of libraries. Is there a: >>/usr/lib/python2.4/config/libpython2.4.so on your machine? > >No. I'm using Suse 9.3, GCC 3.3.5, CMake 2.2-patch 3, SWIG version 1.3.21, >and python 2.4. > >ls -l /usr/lib/python2.4/

Re: [CMake] FindPythonLibs

CMake should prefer the shared versions of libraries. Is there a: /usr/lib/python2.4/config/libpython2.4.so on your machine? No. I'm using Suse 9.3, GCC 3.3.5, CMake 2.2-patch 3, SWIG version 1.3.21, and python 2.4. ls -l /usr/lib/python2.4/config/ total 1682 -rw-r--r-- 1 root root49

Re: [CMake] FindPythonLibs

CMake should prefer the shared versions of libraries. Is there a: /usr/lib/python2.4/config/libpython2.4.so on your machine? Since CMake uses -L, I am thinking there must not be a linkable .so in the same directory as the .a. Where is your shared version of python located? -Bill At 05:43 PM

[CMake] FindPythonLibs

So FindPythonLibs seems to favor the static version of python that is found in /usr/lib/python?.?/config . This is find and dandy until you try to call some swigged code from an embedded python interpreter. Swig will compile an interface library (called _example.so). This will be statically