Part of the problem is that there is no way to force the default CMake modules for finding an python interpreter and python libraries to agree on the same version. As a way around that I wrote my own FindPython.cmake:
https://bitbucket.org/ompl/ompl/src/tip/CMakeModules/FindPython.cmake You can then specify a specific version: find_package(python 3.4) This will define PYTHON_EXEC, PYTHON_LIBRARIES, PYTHON_INCLUDE_DIRS, PYTHON_SITE_MODULES, and PYTHON_VERSION. If you run cmake like so: cmake -DPYTHON_EXEC=/opt/local/bin/python3.4 .. then the other variables are automatically defined appropriately. You can also use it to find python modules: find_python_module(numpy [version] [REQUIRED|QUIET]) Best, Mark > On Jun 22, 2015, at 4:01 PM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > Hi, > > I have a CMake file that has the following, hopefully self-explanatory, bit: > > {{{ > find_package(PythonLibs 3.4.3 REQUIRED) > if ( NOT ${PYTHONLIBS_FOUND} OR ${PYTHON_VERSION_MINOR} GREATER 4 ) > message(FATAL_ERROR "Python 3.4.3 with --enable-shared is required") > endif() > }}} > > The only thing that did was picking up an old 2.4.3 (!) framework I'd > installed as /Library/Frameworks/Python2.4.framework; after removing that it > finds nothing at all. > I had a comparable issue with `find_package(PythonInterp 3.0 required)` which > I could resolve by hardcoding the PYTHON_EXECUTABLE variable, but I don't > think one can pull a similar trick with the PythonLibs script. > > Is there a clean way out, I'm surely not the first one to try this? > > Thanks, > R. > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
