The build package installs an entry point now, so we run that instead of
calling the module directly.
(From OE-Core rev: e064e71b4003666de1644f8e3c08ed6844d710e5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For the build process to actually work some inherits are always needed:
- python3native for the python that is actually running build.
- setuptools3-base (badly named) defines how to build extensions and
where to put modules.
Instead of inheriting these in every class, inherit them once in the
python_pep517 class.
(From OE-Core rev: 449b226aca6a5db378dc5576dde47499925dfb26)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the CONFIGURE_FILES assignment from python_mesonpy to the common
class, as it isn't specific to mesonpy.
Also extend, so that it doesn't clobber existing settings.
(From OE-Core rev: 049cd6b62853c020b0c85ccee18638ec58887866)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python modules install metadata into a .dist-info directory, one of which
is RECORD, which contains the files that were installed and their
checksum[1]. This is typically used by pip to validate the install, or
to know what files to remove when the module is uninstalled.
This is slightly problematic when we need to do patching of installed
.py files in do_install(), as the RECORD file has already been written
at that point.
However, the RECORD files only really have a use outside of a system-
managed environment, which our python packages are. We already have
commands to verify and remove modules (opkg, dpkg, rpm) and the RECORD
file existing simply allows people to 'sudo pip' and alter the package-
managed directories outside of the package manager.
This is not a good idea, and some other distros remove the RECORD file
to stop this possibility:
- Debian[2]
- Fedora[3]
- Gentoo[4]
We can follow for all packages which inherit python_pep517, which is the
majority of the Python packages now.
[1] https://peps.python.org/pep-0491/#the-dist-info-directory
[2] https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dhpython/fs.py?ref_type=heads#L185
[3] https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/macros.pyproject#_105
[4] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=73c49f3c00415dee99407dabba8d3b22895c9d25
(From OE-Core rev: 917df5ed022f9512473fe0971db48b5253c97b85)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The install task uses a recursive find to check that it can only find
one wheel, but then does a non-recursive glob to install. This can
lead to false-failures if PEP517_WHEEL_PATH points at a directory with
subdirectories.
Solve this mismatch by making the find non-recusive.
(From OE-Core rev: 0142da4768b7818b94601a89bf867e10a0ba0ec0)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that the bootstrap sequence for pypa/build is just
python3-packaging, and python3-pyproject-hooks, we can use build instead
of picobuild.
The only change visible outside of this class is that the variable
PEP517_PICOBUILD_OPTS is now PEP517_BUILD_OPTS, but I'm only aware of one
recipe that used that variable.
(From OE-Core rev: 202c2e3c9481a8841af2556862a76e27d703246d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
