Depending on execution order the `python-package-install.sh`
script would return a non-zero err code.
So, this enforces that all commands in the script
don't fail (via the `set -e` directive).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Similar to LEDE/OpenWrt's Build/Compile/Default rule,
and other similarities like this.
This should allow Python packages to define
PyBuild/Compile rules to do specific stuff per
package.
The advantage of using these (over just overriding
Build/Compile) is the VARIANT mechanism that is
in place to support packaging both for Python & Python3.
So, PyBuild/Compile will get picked up for the Python
variant build, and Py3Build/Compile will get picked
up for the Python3 variant build.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Fixes: https://github.com/openwrt/packages/issues/4548
When running parallel jobs, there are chances
that the Build/InstallDev rule may run before
the Host/Install rule and fail the build.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
If you build python/python3 and later decide to build
python(3)-setuptools and/or python(3)-pip, the build won't
re-run without adding `CONFIG_PACKAGE_python(3)-setuptools`
and `CONFIG_PACKAGE_python(3)-pip`.
Seems to resolve issue:
https://github.com/openwrt/packages/issues/4529
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems it's called underlinking that's happening only
on Ubuntu 12.04 with libressl (that comes from LEDE's
tools folder).
Link here:
https://ubuntuforums.org/showthread.php?t=1870586
I'm still reading about this a bit.
Since I don't really get it.
But applying that fix (as in the link) seems to fix compiling
on Ubuntu 12.04, and tried also on 16.04 (to make sure).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
The Build/InstallDev rule is activated only for target builds.
But if someone needs only the host Python, then
these files need to be installed in this phase, and not Build/InstallDev
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I admit this may be be a bit aggressive, but the lang
folder is getting cluttered/filled up with Python, PHP, Perl,
Ruby, etc. packages.
Makes sense to try to group them into per-lang folders.
I took the Pythons.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
