This adds a patch (submitted upstream in
https://github.com/PyO3/setuptools-rust/pull/364), to read the profile
to pass to cargo from an environment variable.
This also updates the Python include files to set the environment
variable based on values from rust-values.mk.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This consolidates all environment variables for cargo into:
* CARGO_HOST_CONFIG_VARS / CARGO_PKG_CONFIG_VARS
These contain all cargo-specific environment variables, i.e. without
"common" variables like CC.
* CARGO_HOST_VARS / CARGO_PKG_VARS (renamed from CARGO_VARS)
These contain all environment variables to be passed to cargo.
This also:
* Set the CARGO_BUILD_TARGET environment variable instead of using the
--target command-line option
* Update Python include files to use CARGO_HOST_CONFIG_VARS /
CARGO_PKG_CONFIG_VARS
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This allows rustc/cargo/etc to be called without having to set PATH, as
$(STAGING_DIR)/host/bin is already in PATH.
This also fixes CARGO_HOME not being set during Host/Configure and
Host/Compile.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This removes the changes made in
61f202c017 and adds actual support for
pyproject.toml-based (PEP 517) builds of Python packages.
Packages can force the use of the old build process by setting
PYTHON3_PKG_FORCE_DISTUTILS_SETUP:=1; this should only be a temporary
workaround until the package can be updated/fixed to use the new build
process.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Using pip to install host packages with pyproject.toml-based (PEP 517)
builds is problematic:
* If build isolation is used, pip will create an isolated build
environment, install any build dependencies for the requested package,
then build the requested package.
It does not appear currently possible to have pip install the build
dependencies with hash-checking mode enabled[1].
* If build isolation is not used, any build dependencies must be
installed in the build environment before invoking pip to build the
requested package[2].
This would require creating a package dependency resolution system to
install build dependencies, and any dependencies of dependencies, in
the correct order.
* It is very difficult to patch the packages installed by pip.
This adds a new include file (python3-host-build.mk) with recipes to
install host Python packages with pyproject.toml-based builds. This is
backwards-compatible with packages that require running setup.py.
Besides addressing the above issues (the OpenWrt build system already
resolves dependencies between packages, checks all source downloads
against known hashes, and supports patching packages), host packages
also:
* Capture package licensing and maintainer information
* Enable uscan checking for package updates/CVEs
* Are a known concept for OpenWrt packagers/developers
The existing functionality of using host pip to install packages will
remain for now, but should be considered deprecated and expected to be
removed in the future.
This also updates Py3Build/CheckHostPipVersionMatch for the case where
the host-pip-requirements directory does not exist or is empty.
[1]: https://pip.pypa.io/en/stable/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020
[2]: https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-no-build-isolation
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This will prevent the user's environment variables from affecting host
Python, removing the need to manually override these variables.
It is also not necessary to set PYTHONPATH (when not working on target
Python packages) because the given directories are already included in
Python's search path by default.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
A new PEP 517 (https://www.python.org/dev/peps/pep-0517/) has defined that
Python packages can be shipped without any `setup.py` file, and that a
`pyproject.toml` file is sufficient.
A `setup.py` shim layer is suggested as a method for running the build.
For these cases, we will add a support in the OpenWrt build-system to
provide the default `setup.py` shim layer in case this file does not exist,
but there is a `pyproject.toml` file.
We also seem to need to tweak the shim layer with the PKG_VERSION,
otherwise the detected version is 0.0.0.
We will need to see if this will be fixed later in setuptools{-scm}.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This also removes PKG_BUILD_PARALLEL:=0 that was added for packages that
use HOST_PYTHON3_PACKAGE_BUILD_DEPENDS.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
In hash-checking mode[1], pip will verify downloaded package archives
(source tarballs in our case) against known SHA256 hashes before
installing the packages.
As a consequence, this requires the use of requirements files[2] and
pinning packages to known versions.
The syntax for package Makefiles has changed slightly;
HOST_PYTHON3_PACKAGE_BUILD_DEPENDS no longer accepts requirement
specifiers like "foo>=1.0", only requirements file names (which are the
same as package names in the most common case).
This also updates affected packages, in particular:
* python-zipp: "setuptools_scm[toml]" has been split into
"setuptools-scm toml" to reuse the requirements file for
setuptools-scm (the extra depends installed by "setuptools_scm[toml]"
is toml).
* python-pycparser: This previously used ply 3.10, whereas the
requirements file will now install 3.11.
[1]: https://pip.pypa.io/en/stable/reference/pip_install/#hash-checking-mode
[2]: https://pip.pypa.io/en/stable/user_guide/#requirements-files
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This adds a config option PYTHON3_HOST_PIP_CACHE_WORLD_READABLE; if
enabled, chmod will be run after pip install to make all
files/directories in the host pip cache world-readable.
Supersedes https://github.com/openwrt/packages/pull/13012.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This lets the Python build process set _PYTHON_HOST_PLATFORM instead of
forcing an explicit value.
Also:
* Save the target _PYTHON_HOST_PLATFORM value during Build/InstallDev
for use when building target Python packages (in python3-package.mk).
* Use the (mostly) default PYTHON_FOR_BUILD value, instead patch
configure to remove the platform triplet from the sysconfigdata file
name.
* Remove the "CROSS_COMPILE=yes" make variable (there is no indication
that this variable is necessary).
* Force host pip to build packages from source instead of downloading
binary wheels.
Previously, host pip can download universal (platform-independent)
wheels but not platform-specific wheels, because of the custom
_PYTHON_HOST_PLATFORM value. (Packages that do not have universal
wheels would be compiled from source.)
With a correct _PYTHON_HOST_PLATFORM, host pip can install
platform-specific wheels as well. However, the pre-built shared object
(.so) files in these wheels will have the host's platform triplet in
their file names. When target Python packages are built (using the
target's _PYTHON_HOST_PLATFORM), Python will not use these shared
object files.
By forcing host pip to build packages from source, the built shared
object files will not have the platform triplet in their file names.
(Host Python has been patched to remove the platform triplet from file
names.) This allows these packages to be used when building target
Python packages.
(The net effect of this complete change is that platform-dependent
packages will continue to be compiled from source, while
platform-independent packages will now also be compiled from source.)
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This changes the recipe name prefix from Build/Compile/HostPy3 to
HostPython3, and clarifies some of the names (RunHost to Run, Mod to
ModSetup).
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
HostPython3 only adds a few environment variables before running host
Python. It has only two users, Build/Compile/HostPy3RunHost and
Build/Compile/HostPy3RunTarget.
HostPython3 also accesses $(PYTHON3PATH), even though python3-host.mk
does not include python3-package.mk, where the variable is defined.
This removes HostPython3 and has its two users run host Python directly.
This also combines the environment variables of HostPython3 and the two
users into HOST_PYTHON3_VARS and PYTHON3_VARS.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Since it only defines variables and canned recipes, it is safe to
include python3-host.mk more than once.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
* Add --cache-dir option to set the pip cache to a directory in
$(DL_DIR), instead of pip's default (build user's ~/.cache/pip),
fixes#9066
* Add --disable-pip-version-check option, since the version check only
prints a message saying a new version is available
* Combine host_python_pip_install and host_python_pip_install_host into
Build/Compile/HostPy[3]PipInstall
* Remove --root and --prefix options, since this function is only used
to install packages to host Python's default site-packages directory
(setting these may serve to confuse pip)
* Pass all of $(HOST_PYTHON[3]_PACKAGE_BUILD_DEPENDS) to the function,
since pip can handle multiple arguments/packages
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
This was copied over from python-packages, when support for installing
packages host-side (via pip) was added.
Based on the discussion on this commit:
612c53fc6c
it was mentioned that removing this may add more benefit in terms of
reducing build time, because packages won't get reinstalled every time.
I'm not entirely sure about any potential side-effects of this, but it's
worth trying it out.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Since `lang/python` is it's own folder of Python packages
(for both Python 2 & 3), and these build rules are needed
in a lot of packages [especially Python packages],
putting them here makes sense architecturally,
to be shared.
This also helps get rid of the `include_mk` construct
which relies on OpenWrt core to provide, and seems
like a broken design idea that has persisted for a while.
Reason is: it requires that Python 2/3 be built to provide
these mk files for other Python packages,
which seems like a bad idea.
Long-term, there could be an issue where some other feeds
would require these mk files [e.g. telephony] for
some Python packages.
We'll see how we handle this a bit later.
For now we limit this to this feed.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Jeffery To