Re: [CMake] Various problems deploying a python module
On 25. Jun, 2010, at 22:30 , Janosch Peters wrote:
On 2010-06-25 18:36:06 +0200, Michael Wild said:
AFAIK all directories you give gcc with the -I option will be searched
_before_ the standard include paths or C_INCLUDE_PATH. So I think you do
have control over what is included. But I know almost nohting about all the
compiling/linking stuff, so I might be wrong.
The problem is the line
#include Python/Python.h
which resolves to /path/to/Python.framework/Headers/Python.h. No way to
specify the version, only the framework location using the -F flag.
Okay. But as Mark Moll pointed out, we could just ignore the -F flag and use
plain Unix include/library paths.
Ignoring -F doesn't matter at all. As soon as gcc sees Python/Python.h it
will pick up /path/to/Python.framework/Headers/Python.h. That's how it works on
Mac. Really, the problem is the Python/ prefix which makes gcc look for a
Python.framework, no matter what. So if you want a specific version to be used,
you have to get creative.
Say your code indeed uses #include Python/Python.h, but you want to let the
user select the actual version of the Python framework that's being used, you
could do the following (completely untried, PYTHON_IS_FRAMEWORK,
PYTHON_FRAMEWORK and PYTHON_VERSION are variables with the obvious content):
if(PYTHON_IS_FRAMEWORK)
set(FW_DIR ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/Frameworks)
file(MAKE_DIRECTORY ${FW_DIR})
execute_process(
COMMAND ${CMAKE_COMMAND} -E remove -f Python.framework
COMMAND ${CMAKE_COMMAND} -E create_symlink
${PYTHON_FRAMEWORK}/Versions/${PYTHON_VERSION}
${FW_DIR}/Python.framework)
add_definitions(-F${FW_DIR})
include_directories(${FW_DIR}/Python.framework/include)
endif()
This code creates a custom Python framework which actually is a symlink to the
desired version.
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-26 01:33:54 +0200, Michael Hertling said: Anyway, one should not take it too lightly; IMO, writing a fully featured, reliable and consistent FindPython.cmake is rather a nontrivial task. True. But it would be great to have sth which performs siginificantly better than the curren scripts. I dont have time for this now, but I might have a look on it in the beginning of august. -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 06/25/2010 03:42 PM, David Cole wrote: I would have thought it was a git commit hash... but I cannot find it at: http://cmake.org/gitweb?p=cmake.git;a=summary Perhaps it's in another git repo? No, it's in your first-order repository: git clone git://cmake.org/cmake.git cd cmake git show 8d87d12 Regards, Michael On Fri, Jun 25, 2010 at 9:17 AM, Janosch Peters j...@binford3000.de wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On Fri, Jun 25, 2010 at 9:42 AM, David Cole david.c...@kitware.com wrote: I would have thought it was a git commit hash... but I cannot find it at: http://cmake.org/gitweb?p=cmake.git;a=summary Perhaps it's in another git repo? Oops. Thanks Michael, for pointing us to http://cmake.org/gitweb?p=cmake.git;a=commit;h=8d87d12 Apparently, I don't know how to use the gitweb search feature correctly. Searching on commit searches the text of the commit... not for its identifier. On Fri, Jun 25, 2010 at 9:17 AM, Janosch Peters j...@binford3000.de wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. -- Mark ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 25. Jun, 2010, at 16:32 , Mark Moll wrote: On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. -- Mark To chime in... For one, the libraries in /usr/lib are symlinked to the framework: $ readlink /usr/lib/libpython2.6.dylib ../../System/Library/Frameworks/Python.framework/Versions/2.6/Python However, I think it's really difficult to guarantee consistency. If the code to be compiled contains stuff like the following #ifdef __APPLE__ #include Python/Python.h #else #include Python.h #endif the compiler will compile against the latest framework installation it finds on the search path (probably /System/Library/Frameworks/Python.framework), but for linking whatever CMake (or the user by modifying the cache) chooses to pick will be used, be that the framework installation or some library-installation (Fink, MacPorts, /usr/lib, user-installed, ...). Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-25 16:32:38 +0200, Mark Moll said: On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. I thought -framework 'path/to/the/framework/you/want/to/use' would work, but I havent tested it. Anyway, your find_package script looks very promising. I'll give it a try. What do you mean by UNIX-biased? Does it work only on Unix/Linux/OS X? Would be great if that script would be considered for one of the next releases. -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-25 16:58:47 +0200, Michael Wild said: However, I think it's really difficult to guarantee consistency. If the code to be compiled contains stuff like the following #ifdef __APPLE__ #include Python/Python.h #else #include Python.h #endif the compiler will compile against the latest framework installation it finds on the search path (probably /System/Library/Frameworks/Python.framework), but for linking whatever CMake (or the user by modifying the cache) chooses to pick will be used, be that the framework installation or some library-installation (Fink, MacPorts, /usr/lib, user-installed, ...). AFAIK all directories you give gcc with the -I option will be searched _before_ the standard include paths or C_INCLUDE_PATH. So I think you do have control over what is included. But I know almost nohting about all the compiling/linking stuff, so I might be wrong. -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On Jun 25, 2010, at 10:05 AM, Janosch Peters wrote: On 2010-06-25 16:32:38 +0200, Mark Moll said: On Jun 25, 2010, at 9:11 AM, Janosch Peters wrote: Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? I suggested the merge, and proposed to add a function to check for the existence of python modules: http://www.cmake.org/pipermail/cmake/2010-June/037468.html On my OS X machine, the headers and libs for different python versions also exist in the more common UNIX places (/usr/include/python2.x, /usr/lib/libpython2.x.dylib, /usr/lib/python2.x/config/libpython2.x.a, and corresponding MacPorts locations). I don’t know of any way you can specify a specific version of a framework, so (at least for python) it seems easier to drop framework support altogether and just use the UNIX paths. I thought -framework 'path/to/the/framework/you/want/to/use' would work, but I havent tested it. Anyway, your find_package script looks very promising. I'll give it a try. What do you mean by UNIX-biased? Does it work only on Unix/Linux/OS X? Right. No attempt is made to use OS X-only frameworks or have it work correctly on Windows. -- Mark ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 25. Jun, 2010, at 17:14 , Janosch Peters wrote: On 2010-06-25 16:58:47 +0200, Michael Wild said: However, I think it's really difficult to guarantee consistency. If the code to be compiled contains stuff like the following #ifdef __APPLE__ #include Python/Python.h #else #include Python.h #endif the compiler will compile against the latest framework installation it finds on the search path (probably /System/Library/Frameworks/Python.framework), but for linking whatever CMake (or the user by modifying the cache) chooses to pick will be used, be that the framework installation or some library-installation (Fink, MacPorts, /usr/lib, user-installed, ...). AFAIK all directories you give gcc with the -I option will be searched _before_ the standard include paths or C_INCLUDE_PATH. So I think you do have control over what is included. But I know almost nohting about all the compiling/linking stuff, so I might be wrong. The problem is the line #include Python/Python.h which resolves to /path/to/Python.framework/Headers/Python.h. No way to specify the version, only the framework location using the -F flag. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-25 18:36:06 +0200, Michael Wild said: AFAIK all directories you give gcc with the -I option will be searched _before_ the standard include paths or C_INCLUDE_PATH. So I think you do have control over what is included. But I know almost nohting about all the compiling/linking stuff, so I might be wrong. The problem is the line #include Python/Python.h which resolves to /path/to/Python.framework/Headers/Python.h. No way to specify the version, only the framework location using the -F flag. Okay. But as Mark Moll pointed out, we could just ignore the -F flag and use plain Unix include/library paths. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 06/25/2010 04:11 PM, Janosch Peters wrote: On 2010-06-25 15:45:37 +0200, Michael Hertling said: On 06/25/2010 03:17 PM, Janosch Peters wrote: On 2010-06-21 07:01:36 +0200, Michael Hertling said: 8d87d12 What's that? Leet speak? No, these are the first seven and sufficiently unambiguous digits of the SHA-1 sum of the commit in CMake's Git repository that removes the framework related lines from FindPythonLibs.cmake Ok. But the python dilemma still remains: 1. FindPythonInterp and FindPythonLibs might still produce inconsistent results (e.g. libs and interpreter of different python versions) 2. AFAIK you cannot specify a specific python version you which to include/link I think someone on the list suggested to merge both modules into one, which would help making the results consistent. Is this (or any other solution) on your todo list? Not on mine - I don't feel sufficiently experienced w.r.t. python, but when thinking about a combined FindPython.cmake, remind the following: http://public.kitware.com/Bug/view.php?id=2257, note #11766 http://www.mail-archive.com/cmake@cmake.org/msg27382.html Therefore, my thoughts about a FindPython.cmake are: 1) FindPython.cmake uses FIND_PACKAGE()'s COMPONENTS option and respects a specified version. 2) There're at least the components interpreter and libraries, and possibly more for modules. 3) Requesting no components at all means requesting interpreter and libraries. 4) Requesting interpreter and libraries means requesting the libraries accompanying the requested interpreter. 5) Requesting solely libraries means looking for the libraries without referring to an interpreter. One of the first apparent problems is how to learn the version when none is specified explicitly since it is necessary to look for the libraries. My suggestion is to provide a variable PYTHON_NATIVE to indicate an interpreter's executability, so the latter can be used to figure out the whole library stuff. Otherwise, one could try to extract the version from the interpreter's name, or try to find an unambiguous library directory. In summary, this may be roughly pseudo-coded as: IF(Python_FIND_COMPONENTS is empty) SET(Python_FIND_COMPONENTS interpreter libraries) ENDIF() IF(Python_FIND_COMPONENTS contains interpreter) # Search an interpreter and respect Python_FIND_VERSION et al. ENDIF() IF(Python_FIND_COMPONENTS contains libraries) IF(Python_FIND_COMPONENTS contains interpreter) # User requested interpreter and libraries, so the latters must # belong to the former; one may be guided by the already found # interpreter, but think whether and when you execute it: IF(PYTHON_NATIVE) # Run the interpreter to locate the associated libraries. ELSEIF(Python_FIND_VERSION) # Search libraries of the requested version. ELSE() # Try to extract the version from the interpreter's name, # e.g. python2.6, or as a last resort, try to find a # single and, thus, unambiguous library directory. ENDIF() ELSE() # User requested solely the libraries, so don't rely on an # interpreter being available; search the libraries as # usual and respect Python_FIND_VERSION et al. ENDIF() ENDIF() So, the user could issue, e.g., SET(PYTHON_NATIVE TRUE) FIND_PACKAGE(Python) to get a consistent native interpreter/libraries combination, or FIND_PACKAGE(Python 2.6 COMPONENTS interpreter libraries) to get a consistent 2.6 interpreter/libraries combination, or FIND_PACKAGE(Python 2.6 COMPONENTS interpreter) FIND_PACKAGE(Python 2.6 COMPONENTS libraries) to get a certain 2.6 interpreter and certain 2.6 libraries, or FIND_PACKAGE(Python 2.5 COMPONENTS interpreter) FIND_PACKAGE(Python 2.4 COMPONENTS libraries) to get the 2.5 interpreter and the 2.4 libraries. Anyway, one should not take it too lightly; IMO, writing a fully featured, reliable and consistent FindPython.cmake is rather a nontrivial task. Regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 06/19/2010 12:31 PM, Janosch Peters wrote:
On 2010-06-18 08:29:25 +0200, Michael Hertling said:
On 06/17/2010 04:23 PM, Janosch Peters wrote:
I have two python frameworks on my mac: Python2.5 which comes with OS
X, and python2.6 from macports. If I just use
FIND_PACKAGE(PythonInterp) and FIND_PACKAGE(PythonLibs) I end up
getting the python2.6 interpreter from macports but the python2.5 libs
from OS X.
Have you already tried variables like CMAKE_PREFIX_PATH et al. to
direct the find functions to your preferred python installation?
I tried CMAKE_PREFIX_PATH and also CMAKE_FRAMEWORK_PATH but the
behaviour did not change. So I digged a bit into the modules code and
found out that the default macports framework prefix is already
recognized when looking for frameworks. However, as you can see in the
snippet below (it's from FindPythonLib), cmake just adds -framework
Python which apperantly defaults to the apple provided frameworks. It
seems to me that you cannot change that behaviour in any way, but by
changing the FindPythonLibs code. Correct me if Im wrong.
Currently, I've no access to a Mac OS X system, so I myself can't test,
but IMO, you're right: Even if PYTHON_LIBRARY and PYTHON_INCLUDE_DIR
are detected as desired FindPythonLibs.cmake sets PYTHON_LIBRARY to
-framework Python if PYTHON_INCLUDE_DIR indicates a framework -
regardless of which. BTW, does PYTHON_INCLUDE_DIR get the right
directory?
BTW, the macro CMAKE_FIND_FRAMEWORKS doesent care about
CMAKE_FRAMEWORK_PATH at all. I would consider that a bug.
Here, I'd also expect the CMAKE_FRAMEWORK_PATH et al. to be recognized,
perhaps along with ARGN for additional explicit framework locations; a
bug report / feature request?
I think the way to go would be to change CMAKE_FIND_FRAMEWORKS to make
it recognise CMAKE_FRAMEWORK_PATH and use the first framework found in
it to pass it to the -frameworks option and if none is found, just
default to the apple system framework.
Alternatively, you could use a modified FindPythonLibs.cmake, i.e.
without the snippet from your latest post concerning frameworks, as a
local CMake module in your project in junction with CMAKE_MODULE_PATH,
or you could resort to FIND_{LIBRARY,PATH}() directly and let CMake
figure out the correct options for linking and including.
For the time being, I think I have to stick to my (very ugly) solution.
...or wait a little as the questionable snippet has gone: 8d87d12 ;)
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-18 08:29:25 +0200, Michael Hertling said:
On 06/17/2010 04:23 PM, Janosch Peters wrote:
I have two python frameworks on my mac: Python2.5 which comes with OS
X, and python2.6 from macports. If I just use
FIND_PACKAGE(PythonInterp) and FIND_PACKAGE(PythonLibs) I end up
getting the python2.6 interpreter from macports but the python2.5 libs
from OS X.
Have you already tried variables like CMAKE_PREFIX_PATH et al. to
direct the find functions to your preferred python installation?
I tried CMAKE_PREFIX_PATH and also CMAKE_FRAMEWORK_PATH but the
behaviour did not change. So I digged a bit into the modules code and
found out that the default macports framework prefix is already
recognized when looking for frameworks. However, as you can see in the
snippet below (it's from FindPythonLib), cmake just adds -framework
Python which apperantly defaults to the apple provided frameworks. It
seems to me that you cannot change that behaviour in any way, but by
changing the FindPythonLibs code. Correct me if Im wrong.
BTW, the macro CMAKE_FIND_FRAMEWORKS doesent care about
CMAKE_FRAMEWORK_PATH at all. I would consider that a bug.
I think the way to go would be to change CMAKE_FIND_FRAMEWORKS to make
it recognise CMAKE_FRAMEWORK_PATH and use the first framework found in
it to pass it to the -frameworks option and if none is found, just
default to the apple system framework.
For the time being, I think I have to stick to my (very ugly) solution.
cheers,
Janosch
= Snippet from FindPythonLibs ==
# Python Should be built and installed as a Framework on OSX
IF(Python_FRAMEWORKS)
# If a framework has been selected for the include path,
# make sure -framework is used to link it.
IF(${PYTHON_INCLUDE_DIR} MATCHES Python\\.framework)
SET(PYTHON_LIBRARY )
SET(PYTHON_DEBUG_LIBRARY )
ENDIF(${PYTHON_INCLUDE_DIR} MATCHES Python\\.framework)
IF(NOT PYTHON_LIBRARY)
SET (PYTHON_LIBRARY -framework Python CACHE FILEPATH Python
Framework FORCE)
ENDIF(NOT PYTHON_LIBRARY)
IF(NOT PYTHON_DEBUG_LIBRARY)
SET (PYTHON_DEBUG_LIBRARY -framework Python CACHE FILEPATH
Python Framework FORCE)
ENDIF(NOT PYTHON_DEBUG_LIBRARY)
ENDIF(Python_FRAMEWORKS)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 06/17/2010 04:23 PM, Janosch Peters wrote: Hi list, I try to write a cmake script for a python module. Its finally working now, but the solution I came up with is not very nice. 1. Finding the correct python environment: I have two python frameworks on my mac: Python2.5 which comes with OS X, and python2.6 from macports. If I just use FIND_PACKAGE(PythonInterp) and FIND_PACKAGE(PythonLibs) I end up getting the python2.6 interpreter from macports but the python2.5 libs from OS X. I solved it by manually setting the path to python2.6 libraries and headers in INCLUDE_DIRECTORIES and TARGET_LINK_LIBRARIES but this is quite ugly because it may break on another system wit a different path prefix for macports. Is there any way to set the desired python version for PythonInterp and PythonLibs in cmake? There has been several disussions of such an issue, e.g. http://www.mail-archive.com/cmake@cmake.org/msg19031.html http://www.mail-archive.com/cmake@cmake.org/msg25197.html and perhaps http://www.mail-archive.com/cmake@cmake.org/msg27324.html which raises hope for a well elaborated FindPython.cmake. ;) Have you already tried variables like CMAKE_PREFIX_PATH et al. to direct the find functions to your preferred python installation? On *nix, e.g., with a python 2.6 installed aside the usual locations but with the interpreter in the PATH and a system's python 2.5 there would be a version mismatch since FindPythonInterp.cmake follows the PATH to 2.6 while FindPythonLibs.cmake ignores the PATH and finds 2.5 through CMAKE_SYSTEM_PREFIX_PATH, so the use of CMAKE_PREFIX_PATH or the like is needed to find the 2.6 libraries as well. However, because the two FindPython modules use hardcoded version specifications in a hardcoded order you shouldn't rely on their capability to find a certain version, cf. http://www.mail-archive.com/cmake@cmake.org/msg28878.html, i.e. in the above-mentioned *nix scenario, e.g., one couldn't force the FindPythonInterp.cmake to find 2.5 if 2.6 can be found, too. 2. Renaming the library file: This is probably very simple, but I startet wih cmake today: How do I change the filename of my library/module? The module is called libvlfeat.so, however python expects C modules to be named _name.so. (In my case _vlfeat.so). How do I do that? SET_TARGET_PROPERTIES(vlfeat PROPERTIES PREFIX _) 'hope that helps. Regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Various problems deploying a python module
On 2010-06-17 16:23:09 +0200, Janosch Peters said: 3. Copy python files during installation The python module needs some python files along with the compiled C module. Currently, I just copy all the stuff using cmakes file() command. That means, all files are created when the user types in cmake .. It would be better if the files would not be copied until the user says make install. Is there a way that the file() commands are somehow converted to similar commands in the makefile? Ok I found out myself that this can be done with the INSTALL command, too. -- Janosch ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
