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>
2018-01-10 23:01:51 +02:00
Renamed from lang/python/python3/files/python3-host.mk (Browse further)
