CMake find_package(PythonInterp 3.7 REQUIRED) for Win32 platform - python

I have some project which supposed to support Win32 and x64 platform.
Some code is generated by python script.
This script uses python3 features.
In CMakeLists.txt I have something like this:
find_package(PythonInterp REQUIRED)
if (CMAKE_CL_64)
set(MY_APP_PLATFORM "x64")
else()
set(MY_APP_PLATFORM "Win32")
endif()
add_custom_command(TARGET MyApp
PRE_BUILD
COMMAND ${PYTHON_EXECUTABLE} ${MyApp_ROOT}/generator.py -p ${MY_APP_PLATFORM }
WORKING_DIRECTORY ${PATH_GENERATED_SRC}
COMMENT "Generating code..."
VERBATIM
)
Quite simple.
Now when project for x64 is used everything works like a charm, but when building for Win32 (cmake have to generate separate project) cmake finds python 2.7.2.
Changing CMakeLists.txt this way:
find_package(PythonInterp 3.7 REQUIRED)
Leads to cmake failure.
Is there way to fix it, or do I have to correct pythons script to be python2 compatible?
Or do I have to install python3 for 32 and 64 bits to cover both platforms?

The CMake Module is FindPython3.cmake in your cmake distribution.
This should work:
find_package(Python3 COMPONENTS Interpreter)
add_custom_command(TARGET MyApp
PRE_BUILD
COMMAND ${PYTHON3_EXECUTABLE} ${MyApp_ROOT}/generator.py -p ${MY_APP_PLATFORM}
WORKING_DIRECTORY ${PATH_GENERATED_SRC}
COMMENT "Generating code..."
VERBATIM
)
It is available since cmake 3.12.
Documentation

Related

CloudCompare's python plugin installation stuck with cmake

I am quite new to coding. so this could be a stupid mistake from my side but pls do help me.
while trying to installing the python plugin,by generating a .dll file and I got stuck at the 5th step (Generate the cmake config) on the documentation (https://github.com/tmontaigu/CloudCompare-PythonPlugin/blob/master/docs/building.rst).
I am using windows 10, CloudCompare v2.12 alpha 64 bit.
my cmake error's screenshot is here
CMake Error
my CMakeLists.txt is here
cmake_minimum_required(VERSION 3.21)
include(cmake/helpers.cmake)
include(cmake/CompilerWarnings.cmake)
option(PLUGIN_PYTHON "Install Python Plugin" OFF)
if(PLUGIN_PYTHON)
project(PythonPlugin)
addplugin(NAME ${PROJECT_NAME})
# set_project_warnings(${PROJECT_NAME})
option(PLUGIN_PYTHON_USE_EMBEDDED_MODULES
"Should the Python wrapper libs be embedded in the plugin" ON
)
mark_as_advanced(PLUGIN_PYTHON_USE_EMBEDDED_MODULES)
if(WIN32)
option(PLUGIN_PYTHON_COPY_ENV
"Should the content of the current python venv be copied on install"
ON
)
mark_as_advanced(PLUGIN_PYTHON_COPY_ENV)
if(NOT PYTHON_EXECUTABLE)
if(DEFINED ENV{CONDA_PREFIX})
list(INSERT CMAKE_PREFIX_PATH 0
"$ENV{CONDA_PREFIX}/Library/share/cmake"
)
set(PYTHON_EXECUTABLE "$ENV{CONDA_PREFIX}/python.exe")
elseif(DEFINED ENV{VIRTUAL_ENV})
set(PYTHON_EXECUTABLE "$ENV{VENV_PREFIX}/Scripts/python.exe")
endif()
endif()
endif()
if(PYTHON_EXECUTABLE)
execute_process(
COMMAND "${PYTHON_EXECUTABLE}" "-m" "pybind11" "--cmake"
RESULT_VARIABLE _PYTHON_SUCCESS
OUTPUT_VARIABLE PYBIND11_CMAKE_MODULES_PATH
)
if(_PYTHON_SUCCESS MATCHES 0)
string(REGEX REPLACE "\n" "" PYBIND11_CMAKE_MODULES_PATH
${PYBIND11_CMAKE_MODULES_PATH}
)
list(INSERT CMAKE_PREFIX_PATH 0 "${PYBIND11_CMAKE_MODULES_PATH}")
endif()
endif()
find_package(pybind11 CONFIG REQUIRED)
add_subdirectory(wrapper)
add_subdirectory(src)
if(PLUGIN_PYTHON_USE_EMBEDDED_MODULES)
target_compile_definitions(PythonPlugin PRIVATE -DUSE_EMBEDDED_MODULES)
embed_cccorelib_in(${PROJECT_NAME})
embed_pycc_in(${PROJECT_NAME})
endif()
target_link_libraries(PythonPlugin pybind11::embed)
set_target_properties(PythonPlugin PROPERTIES CXX_VISIBILITY_PRESET hidden)
if(WIN32)
manage_windows_install()
elseif(UNIX AND NOT APPLE)
if(NOT PLUGIN_PYTHON_USE_EMBEDDED_MODULES)
installsharedlibrary(TARGET cccorelib)
installsharedlibrary(TARGET pycc)
endif()
endif()
endif()
after the generation of pyccvenv virtual environment, my python.exe is placed at C:\Windows\System32\pyccvenv\Scripts\python.exe
if these informations are sufficient please do help me.
and I would also like to know if it is possible to install the plugin with the .dll file that's been already generated by someone else, if yes please do share the python plugin's .dll file so that my installation will be at ease

numpy/ndarrayobject.h: No such file or directory

I am trying to compile a project using cmake. This is the relevant CMakeLists.txt code snippet.
set(PYTHON3_NUMPY_INCLUDE_DIRS=/usr/local/lib/python3.6/dist-packages/numpy/core/include/)
set(PYTHON_INCLUDE_DIRS ${PYTHON_INCLUDE_DIRS} /usr/local/lib/python3.6/dist-packages/numpy/core/include)
find_package(Python COMPONENTS Interpreter Development)
find_package(PythonLibs REQUIRED)
...
include_directories( ${PYTHON_INCLUDE_DIRS} )
To ensure that it is working properly, I print the relevant info
execute_process ( COMMAND ${PYTHON_EXECUTABLE} -c "import numpy; print(numpy.get_include())" OUTPUT_VARIABLE NUMPY_INCLUDE OUTPUT_STRIP_TRAILING_WHITESPACE)
message (STATUS "NUMPY_INCLUDE: " ${NUMPY_INCLUDE})
This is how I compile
cmake -DPYTHON_EXECUTABLE=/usr/bin/python3 .
Here is my output of cmake, the relevant bits.
-- Found Python: /usr/bin/python3.6 (found version "3.6.9") found components: Interpreter Development
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found version "3.6.9")
-- NUMPY_INCLUDE: /usr/local/lib/python3.6/dist-packages/numpy/core/include
So far everything is perfect and numpy is found.
However, on running make, I get the following
fatal error: numpy/ndarrayobject.h: No such file or directory
#include <numpy/ndarrayobject.h>
From what I can see I've covered all bases, yet I'm getting this error. What do I do?

Building Qscintilla2 python bindings on Windows7 with MinGW (PyQt4.11, Qt4.8.6)

I've tried to resolve this prolem for about 3days, and I'd finally felt that I need to ask for help by creating my own question.
I have Windows 7x64 and Qt4.8.6 installed.
I need Python with PyQt and Qscintilla2 to be installed and working.
Now I wil describe my last actions. I did everything like included packages instructions said.
1) Installed Python2.7.9 32bit from official website.
2) Downloaded SIP from here (dev snapshot), then:
configure.py —platform win32-g++
mingw32-make
mingw32-make install
3) Downloaded PyQt from here (not the installer but dev snapshot, cause I need to build with MinGW and istaller producec MSVC version), then:
configure-ng.py -spec win32-g++
mingw32-make
mingw32-make install
Ater these steps I tested PyQt on my project - everything works fine.
Then I starded trying to install Qsnitilla2.
4) Downloaded Qsnitilla2 from here (dev snapshot), then:
a) in Qt4Qt5 folder:
qmake qscintilla.pro -spec win32-g++
mingw32-make
mingw32-make install
This had installed Qsnitilla2 in Qt4.8.6 as I saw;
b) in Python folder( F..ing Python bindngs, excuse my french):
config.py —spec win32-g++
mingw32-make
after this I got ld.exe error (linking error):
Then, afted doing some research, I manually edited my Makefile.Release (by adding -lpython27 to LIBS parameter):
LIBS = -L"c:\Qt-mingw\4.8.6\lib" -LC:\Python27\libs -LC:\Qt-mingw\4.8.6\lib -lqscintilla2 -lQtGui4 -lQtCore4 -lpython27
After this, my mingw32-make completed succesfully. So:
mingw32-make install
This had installed Qscintilla2 Python bindings.
Now I can see Qsci autocomlplete in Eclipse.
So i've tried this:
from PyQt4.Qsci import QsciScintilla
And i've got this in traceback:
from PyQt4.Qsci import QsciScintilla
ImportError: DLL load failed: Не найден указанный модуль
(Translation: The specified module could not be found)
I've tried this with both dev snapshot and src packages from Riverbank website. And also with MinGW 4.8.1 and MinGW-w64 4.8.4. I can't use MinGW-w64 over 4.8 version cause I need boost-1.55 and it only supports MinGW 4.8.
I don't know what to do now, but I really want to use Scintilla in my project. So i'll be very gratefull for any suggestions.
Have you ever tried to load the QsciScintilla right from the console? I mean you need to enter the directory where the QScintilla located( this means current folder is the default folder), then try run the command "from PyQt4.Qsci import QsciScintilla", if this load module failure still happens, this possibly means you need extra dynamic which QScintilla depends, you need to use dll dependency to find out if some other libraries were missing, then put the missing libraries into the same folder of QsciScintilla.

Compiling vim with specific version of Python

I'm working on several Python projects who run on various versions of Python. I'm hoping to set up my vim environment to use ropevim, pyflakes, and pylint but I've run into some issues caused by using a single vim (compiled for a specific version of Python which doesn't match the project's Python version).
I'm hoping to build vim into each of my virtualenv directories but I've run into an issue and I can't get it to work. When I try to build vim from source, despite specifying the Python config folder in my virtualenv, the system-wide Python interpreter is always used.
Currently, I have Python 2.6.2 and Python 2.7.1 installed with several virtualenvs created from each version. I'm using Ubuntu 10.04 where the system-default Python is 2.6.5. Every time I compile vim and call :python import sys; print(sys.version) it returns Python 2.6.5.
configure --prefix=/virtualenv/project --enable-pythoninterp=yes --with-python-config-dir=/virtualenv/project/lib/python2.6/config
Results in the following in config.log:
...
configure:5151: checking --enable-pythoninterp argument
configure:5160: result: yes
configure:5165: checking for python
configure:5195: result: /usr/bin/python
...
It should be /virtualenv/project/bin/python. Is there any way to specify the Python interpreter for vim to use?
NOTE: I can confirm that /virtualenv/project/bin appears at the front of PATH environment variable.
I'd recommend building vim against the 2 interpreters, then invoking it using the shell script I provided below to point it to a particular virtualenv.
I was able to build vim against Python 2.7 using the following command (2.7 is installed under $HOME/root):
% LD_LIBRARY_PATH=$HOME/root/lib PATH=$HOME/root/bin:$PATH \
./configure --enable-pythoninterp \
--with-python-config-dir=$HOME/root/lib/python2.7/config \
--prefix=$HOME/vim27
% make install
% $HOME/bin/vim27
:python import sys; print sys.path[:2]
['/home/pat/root/lib/python27.zip', '/home/pat/root/lib/python2.7']
Your virtualenv is actually a thin wrapper around the Python interpreter it was created with -- $HOME/foobar/lib/python2.6/config is a symlink to /usr/lib/python2.6/config.
So if you created it with the system interpreter, VIM will probe for this and ultimately link against the real interpreter, using the system sys.path by default, even though configure will show the virtualenv's path:
% PATH=$HOME/foobar/bin:$PATH ./configure --enable-pythoninterp \
--with-python-config-dir=$HOME/foobar/lib/python2.6/config \
--prefix=$HOME/foobar
..
checking for python... /home/pat/foobar/bin/python
checking Python's configuration directory... (cached) /home/pat/foobar/lib/python2.6/config
..
% make install
% $HOME/foobar/bin/vim
:python import sys; print sys.path[:1]
['/usr/lib/python2.6']
The workaround: Since your system vim is most likely compiled against your system python, you don't need to rebuild vim for each virtualenv: you can just drop a shell script named vim in your virtualenv's bin directory, which extends the PYTHONPATH before calling system vim:
Contents of ~/HOME/foobar/bin/vim:
#!/bin/sh
ROOT=`cd \`dirname $0\`; cd ..; pwd`
PYTHONPATH=$ROOT/lib/python2.6/site-packages /usr/bin/vim $*
When that is invoked, the virtualenv's sys.path is inserted:
% $HOME/foobar/bin/vim
:python import sys; print sys.path[:2]
['/home/pat/foobar/lib/python2.6/site-packages', '/usr/lib/python2.6']
For what it's worth, and no one seems to have answered this here, I had some luck using a command line like the following:
vi_cv_path_python=/usr/bin/python26 ./configure --includedir=/usr/include/python2.6/ --prefix=/home/bcrowder/local --with-features=huge --enable-rubyinterp --enable-pythoninterp --disable-selinux --with-python-config-dir=/usr/lib64/python2.6/config
I would like to give a similar solution to crowder's that works quite well for me.
Imagine you have Python installed in /opt/Python-2.7.5 and that the structure of that folder is
$ tree -d -L 1 /opt/Python-2.7.5/
/opt/Python-2.7.5/
├── bin
├── include
├── lib
└── share
and you would like to build vim with that version of Python. All you need to do is
$ vi_cv_path_python=/opt/Python-2.7.5/bin/python ./configure --enable-pythoninterp --prefix=/SOME/FOLDER
Thus, just by explicitly giving vi_cv_path_python variable to configure the script will deduce everything on it's own (even the config-dir).
This was tested multiple times on vim 7.4+ and lately with vim-7-4-324.
I was having this same issue with 3 different versions of python on my system.
for me the easiest thing was to change my $PATH env variable so that the folder that has the version of python I wanted was (in my case /usr/local/bin) was found before another.
During my compiling vim80, the system python is 2.6, I have another python 2.7 under ~/local/bin, I find that, to make the compiling work:
update $PATH to place my python path ahead
add a soft link, ln -s python python2 ( the configure file would try to locate python config by probing python2 )
make distclean before re-run ./configure to make sure no cached wrong value is picked.

How to link C lib against python for embedding under Windows?

I am working on an application written in C. One part of the application should embed python and there is my current problem. I try to link my source to the Python library but it does not work.
As I use MinGW I have created the python26.a file from python26.lib with dlltool and put the *.a file in C:/Program Files (x86)/python/2.6/libs.
Therefore, I compile the file with this command:
gcc -shared -o mod_python.dll mod_python.o "-LC:\Program Files (x86)\python\2.6\libs" -lpython26 -Wl,--out-implib,libmod_python.a -Wl,--output-def,mod_python.def
and I get those errors:
Creating library file: libmod_python.a
mod_python.o: In function `module_init':
mod_python.c:34: undefined reference to `__imp__Py_Initialize'
mod_python.c:35: undefined reference to `__imp__PyEval_InitThreads'
... and so on ...
My Python "root" folder is C:\Program Files (x86)\python\2.6
The Devsystem is a Windows Server 2008
GCC Information: Reading specs from C:/Program Files (x86)/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
What I do wrong? How I get it compiled and linked :-)?
Cheers, gregor
Edit:
I forgot to write information about my Python installation: It's the official python.org installation 2.6.1
... and how I created the python.a file:
dlltool -z python.def --export-all-symbols -v c:\windows\system32\python26.dll
dlltool --dllname c:\Windows\system32\python26.dll --def python.def -v --output-lib python26.a
Well on Windows the python distribution comes already with a libpython26.a in the libs subdir so there is no need to generate .a files using dll tools.
I did try a little example with a single C file toto.c:
gcc -shared -o ./toto.dll ./toto.c -I/Python26/include/ -L/Python26/libs -lpython26
And it works like a charm. Hope it will help :-)
Python (at least my distribution) comes with a "python-config" program that automatically creates the correct compiler and linker options for various situations. However, I have never used it on Windows. Perhaps this tool can help you though?
IIRC, dlltool does not always work. Having python 2.6 + Wow makes things even more less likely to work. For numpy, here is how I did it. Basically, I use obdump.exe to build the table from the dll, which I parse to generate the .def. You should check whether your missing symbols are in the .def, or otherwise it won't work.

Categories

Resources