summaryrefslogtreecommitdiffstats
path: root/meta/classes/python3native.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* Convert to new override syntaxRichard Purdie2021-08-021-1/+1
| | | | | | | | | | | | This is the result of automated script conversion: scripts/contrib/convert-overrides.py <oe-core directory> converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3: split python target configuration into own classAlexander Kanavin2020-11-161-2/+0
| | | | | | | | | | | | | | | | | | | | Setting _PYTHON_SYSCONFIGDATA_NAME in python3native class globally was problematic as it was leaking into host python environment, which was causing tracebacks depending on host distro and action (typically anything involving importing sysconfig module). The new class sets the variable only in specific tasks where it is needed, and should be inherited explicitly: - use python3native to run scripts with native python - use python3targetconfig to run scripts with native python if those scripts need to access target config data (such as correct installation directories). This also adds a dependency on target python, so should be used carefully to avoid lengthening builds. (From OE-Core rev: 5a118d4e7985fa88f04c3611f8db813f0dafce75) Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: fix Python executable with cmakeMartin Kelly2020-04-051-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, CMake has two ways of finding Python executables: FindPythonInterp and FindPython/FindPython3. FindPythonInterp is deprecated and may be removed at some point. Currently, python3native sets PYTHON_EXECUTABLE, which FindPythonInterp uses. This is a problem for a few reasons: - Setting PYTHON_EXECUTABLE as an environment variable doesn't work, as CMake needs it to be set as an explicit CMake option via -D. - Projects using the newer FindPython/FindPython3 don't pickup the right Python, as the newer routines use Python_EXECUTABLE and Python3_EXECUTABLE. Fix this by setting PYTHON_EXECUTABLE, Python_EXECUTABLE, and Python3_EXECUTABLE using -D options to EXTRA_OECMAKE. The CMake routines are documented below: https://cmake.org/cmake/help/latest/module/FindPythonInterp.html https://cmake.org/cmake/help/latest/module/FindPython.html https://cmake.org/cmake/help/latest/module/FindPython3.html (From OE-Core rev: a22200a646eaf42cd4902a2fe3358d29717ac129) Signed-off-by: Martin Kelly <mkelly@xevo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3native: set PYTHON_EXECUTABLE for CMakeRoss Burton2019-12-041-0/+2
| | | | | | | | | | This ensures cmake uses the correct python binary rather than potentially, the host system one. (From OE-Core rev: afb8d456360d86254ab00f05866c34d947d02749) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3native, pythonnative: export PYTHON_LIBRARY and PYTHON_INCLUDE_DIRKhem Raj2019-09-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | packages can use find_package(PythonInterp REQUIRED) find_package(PythonLibs REQUIRED) while we control PYTHON pointing to native py3 the libs and include directories will then point to build host version, which can result in unexpected combination and if we are lucky we get errors if its quite different e.g. py2 libs/includes and py3 executable This variable can be then used to export PYTHON_LIBRARY and PYTHON_INCLUDE_DIR so that above find_packages can work correctly see [1] for how it happens in cmake LLDB uses it see [2] [1] https://github.com/Kitware/CMake/blob/master/Modules/FindPythonLibs.cmake [2] https://github.com/llvm/llvm-project/blob/master/lldb/cmake/modules/LLDBConfig.cmake#L226 (From OE-Core rev: e45c06fe6f9a21c2cd06ae003cb112556382f81e) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3: upgrade to 3.7.2Alexander Kanavin2019-02-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I took the same approach as the recent perl upgrade: write recipe from scratch, taking the pieces from the old recipe only when they were proven to be necessary. The pgo, manifest and ptest features are all preserved. New features: - native and target recipes are now unified into one recipe - check_build_completeness.py runs right after do_compile() and verifies that all optional modules have been built (a notorious source of regressions) - a new approach to sysconfig.py and distutils/sysconfig.py returning values appropriate for native or target builds: we copy the configuration file to a separate folder, add that folder to sys.path (through environment variable that differs between native and target builds), and point python to the file through another environment variable. There were a few other patches where it was difficult to decide if the patch is still relevant, and how to test that it works correctly; please add those as-needed by testing the new python. (From OE-Core rev: 02714c105426b0d687620913c1a7401b386428b6) Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python[3]native: allow use of both native Python 2 and 3Ross Burton2018-08-021-3/+3
| | | | | | | | | | | | | | Instead of both classes using ${PYTHON_PN} (which is set by python-dir and python3-dir), hardcode the right values so that it is possible to inherit both pythonnative and python3native at the same time. If both are inherited then both native Pythons are available, but the last to be inherited will be the one to set PYTHON. (From OE-Core rev: 96ccdadb8473daa3c9c2e1cb42fbdff1edd270d6) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python*native.bbclass: suppress user site dirsMartin Kelly2017-09-141-0/+3
| | | | | | | | | | | Currently, $HOME/.local is being added into sys.path for the native Python, causing subtle host contamination. Suppress this by exporting PYTHONNOUSERSITE = "1" as documented in PEP 370. (From OE-Core rev: 8fe9fb4d5a61dcbcb3fc5b9ee0234cc135af873f) Signed-off-by: Martin Kelly <mkelly@xevo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* pythonnative.bbclass, python3native.bbclass: use DEPENDS_append instead of ↵Alexander Kanavin2016-07-011-1/+1
| | | | | | | | | | | | | DEPENDS += Otherwise -native variants of recipes that use these classes don't get a proper python[3]-native dependency for some reason. (From OE-Core rev: 834514198f9e39ce323270567e3ce744f763b637) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* pythonnative.bbclass, python3native.bbclass: export STAGING_INCDIR, ↵Alexander Kanavin2016-07-011-0/+8
| | | | | | | | | | | | | | | | | | | | | | | STAGING_LIBDIR, PYTHON variables We patch Python's distutils modules to access STAGING_INCDIR/LIBDIR, so when they are not set, scripts that utilize distutils (e.g. python-config) fail. Several recipes need to export those manually to prevent such failures, so let's do that in the class instead. PYTHON variable is exported because otherwise autotools' python.m4 macro will pick up its own internal default, which may not be the version that we want. glib recipe in particular was previously using Python 2.x during build due to python.m4 defaulting to it - now it's using Python 3.x, and so needs a small fix in deletion of *.pyc files. (From OE-Core rev: c1e0eb62f2d89b10b187016200018830b1c77945) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3-dir.bbclass: add a separate class for Python 3Alexander Kanavin2016-06-011-3/+1
| | | | | | | | | | This is much cleaner than sharing python-dir.bbclass between python 2 and 3 classes, and doing confusing overrides in them. (From OE-Core rev: 3891fcec863602a0ae6d0f3d305ea50a79a205d9) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3: Upgrade from 3.4.3 to 3.5Alejandro Hernandez2015-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | python3-native_3.4.3.bb -> python3-native_3.5.0.bb: - changed version - changed cheksum - no license change, just dates python3_3.4.3.bb -> python3_3.5.0.bb: - changed version - changed cheksum - no license change, just dates New: - use_packed_importlib.patch: Fixes importlib on cross-compile environments Rebased: - Manifest - 000-cross-compile.patch - 020-dont-compile-python-files.patch - 04-default-is-optimized.patch - python-3.3-multilib.patch - distutils3-base.bbclass - distutils3-native-base.bbclass - python3native.bbclass Upstream: - makerace.patch Misc: - pip2 is handled as default on major distros, modified python3-pip to leave /usr/bin/pip available for pip2 - Fixed importing pip3 from python3 interpreter (From OE-Core rev: 701ec1977ced1bb08461e6de98b4f63d21cba8a6) Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3: Change python BASEVERSION to 3.4Alejandro Hernandez2015-05-071-1/+1
| | | | | | | | | | Changes PYTHON_BASEVERSION = 3.4 to fix errors when installing python3-distribute and probably other libraries (From OE-Core rev: 59bad496fb57fdc5356ddc343f58eb69ff207863) Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* python3native.bbclass: Add python3 abstraction classKhem Raj2014-02-021-0/+7
(From OE-Core rev: ead30aa5e3046f450ee688e14f6d5268d9ed0bd8) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-01-15 21:09:49 +0000