linux/poky.git/meta/classes/python3native.bbclass, branch mickledore-next

classes: Update classes to match new bitbake class scope functionality

2022-08-12T14:27:17+00:00

Move classes to classes-global or classes-recipe as appropriate to take advantage of new bitbake functionality to check class scope/usage. (From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045) Signed-off-by: Richard Purdie

classes: Add SPDX license identifiers

2022-08-12T10:58:01+00:00

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. (From OE-Core rev: 081a391fe09a21265881e39a2a496e4e10b4f80b) Signed-off-by: Richard Purdie

classes: Add copyright statements to files without one

2022-08-12T10:58:01+00:00

Where there isn't a copyright statement, add one to make it explicit. Also drop editor config lines where they were present. (From OE-Core rev: 880c1ea3edc8edef974e65b2d424fc36809ea034) Signed-off-by: Richard Purdie

python3native.bbclass: distutils -> sysconfig

2022-01-12T21:09:02+00:00

In the comment it says we patch distutils modules, but we now are patching sysconfig and not using distutils. [YOCTO #14610] (From OE-Core rev: 4f196b26d80305366d06ad51f44dd26ce81bea16) Signed-off-by: Tim Orling Signed-off-by: Richard Purdie

Convert to new override syntax

2021-08-02T14:44:10+00:00

This is the result of automated script conversion: scripts/contrib/convert-overrides.py converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie

python3: split python target configuration into own class

2020-11-16T14:27:46+00:00

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 Signed-off-by: Richard Purdie

cmake: fix Python executable with cmake

2020-04-05T10:46:38+00:00

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 Signed-off-by: Richard Purdie

python3native: set PYTHON_EXECUTABLE for CMake

2019-12-04T12:30:59+00:00

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 Signed-off-by: Richard Purdie

python3native, pythonnative: export PYTHON_LIBRARY and PYTHON_INCLUDE_DIR

2019-09-07T06:47:24+00:00

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 Signed-off-by: Richard Purdie

python3: upgrade to 3.7.2

2019-02-08T10:57:19+00:00

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 Signed-off-by: Richard Purdie