summaryrefslogtreecommitdiffstats
path: root/meta/classes/python3native.bbclass
AgeCommit message (Collapse)Author
2022-08-12classes: Update classes to match new bitbake class scope functionalityRichard Purdie
Move classes to classes-global or classes-recipe as appropriate to take advantage of new bitbake functionality to check class scope/usage. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-08-12classes: Add SPDX license identifiersRichard Purdie
As stated in our top level license files, the license is MIT unless otherwise stated. Add SPDX identifers accordingly. Replace older license statementa with the standardised syntax. Also drop "All Rights Reserved" expression as it isn't used now, doesn't mean anything and is confusing. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-08-12classes: Add copyright statements to files without oneRichard Purdie
Where there isn't a copyright statement, add one to make it explicit. Also drop editor config lines where they were present. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-01-12python3native.bbclass: distutils -> sysconfigTim Orling
In the comment it says we patch distutils modules, but we now are patching sysconfig and not using distutils. [YOCTO #14610] Signed-off-by: Tim Orling <tim.orling@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-07-30Convert to new override syntaxRichard Purdie
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 "_". Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-11-16python3: split python target configuration into own classAlexander Kanavin
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. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-04-03cmake: fix Python executable with cmakeMartin Kelly
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 Signed-off-by: Martin Kelly <mkelly@xevo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-12-04python3native: set PYTHON_EXECUTABLE for CMakeRoss Burton
This ensures cmake uses the correct python binary rather than potentially, the host system one. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-09-07python3native, pythonnative: export PYTHON_LIBRARY and PYTHON_INCLUDE_DIRKhem Raj
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 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-02-08python3: upgrade to 3.7.2Alexander Kanavin
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. Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-08-02python[3]native: allow use of both native Python 2 and 3Ross Burton
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. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-13python*native.bbclass: suppress user site dirsMartin Kelly
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. Signed-off-by: Martin Kelly <mkelly@xevo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-07-01pythonnative.bbclass, python3native.bbclass: use DEPENDS_append instead of ↵Alexander Kanavin
DEPENDS += Otherwise -native variants of recipes that use these classes don't get a proper python[3]-native dependency for some reason. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-01pythonnative.bbclass, python3native.bbclass: export STAGING_INCDIR, ↵Alexander Kanavin
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. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-05-30python3-dir.bbclass: add a separate class for Python 3Alexander Kanavin
This is much cleaner than sharing python-dir.bbclass between python 2 and 3 classes, and doing confusing overrides in them. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
2015-12-01python3: Upgrade from 3.4.3 to 3.5Alejandro Hernandez
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 Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-05-05python3: Change python BASEVERSION to 3.4Alejandro Hernandez
Changes PYTHON_BASEVERSION = 3.4 to fix errors when installing python3-distribute and probably other libraries Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-02-02python3native.bbclass: Add python3 abstraction classKhem Raj
Signed-off-by: Khem Raj <raj.khem@gmail.com>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-05-01 11:11:21 +0000