The sets host Python's prefix and exec-prefix to the same value
($(STAGING_DIR)/host for packages, as currently defined in
include/host-build.mk), which avoids the case where pyconfig.h is
not in the same location as Python's other header files (see
https://bugs.python.org/issue896330).
This also removes some cross compilation workarounds
(_python_sysroot/prefix/exec_prefix, disabling byte-compilation,
__PYVENV_LAUNCHER__) that are not necessary when compiling packages
for host.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
AFAIK sysroot is combined with prefix/exec_prefix, so sysroot shouldn't
include "/usr". (cf. the HostPython function in older versions of
python-package.mk)
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Seems those pkgconfig file paths were revealed to be incorrect
after doing a full clean build.
And I only had to inspiration to do one after doing the initial PR.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And split python-dev and python-lib2to3 packages.
Seems for python3 this was done, so we'll sync here.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
That means basically moving the host Python from $(STAGING_DIR_HOST)
to $(STAGING_DIR_HOST)/usr and making the PYTHONPATH var
as an argument.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some python packages (e.g. cffi) compile one or more shared libraries
as part of their setup process. When these packages are setup
dependencies of other packages (e.g. cryptography), these packages (and
their shared libraries) will need to be loaded on the host system.
This adds a makefile, similar to python-package.mk, to simplify
installing python packages on the host.
Signed-off-by: Jeffery To <jeffery.to@gmail.com>
Since 94f87dc1, host build of Python depends on expat installed in host
staging directory. However, pyexpat extension fails to build if expat
was not built and installed to staging dir before - adding host build
dependency should fix this.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Build depends must refer to the source package name, not the binary one,
therefore we need to use `bzip2` in order to enforce a build of libbz2.so.
Also make the host python build depend on the bzip2 host build in order to
ensure that host python is built with bzip2 support. We don't need a build
dependency for the target python as this already depends on +libbz2 through
python-light. That package dependency in turn implies a build dependency.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
Patch removing multiarch paths from build should be applied only when
Python is built for target, but not for host. When the paths are removed
during host build, host python throws some ugly errors when importing
some hashlib modules. Also it reports that modules crypt and nis failed
to build (tested on Ubuntu 14.04 host).
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Seems removing the PyPackage rule and/or adding dummy install rule
causes some issues inside the build-system, where the libpython2.7.so.1.0
is not seen by packages that depend on python.
Even though that libpython2.7.so.1.0 file is installed properly by `python-base`.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Calling `PyPackage` will install some default install rules for
python packages that are not required for the `python` package specifically
are not required.
That will lead to some conflicts with `python-light` because the
`/usr/lib/python2.7/site-packages` folder (+contents) will be
available in both packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Packetize some Python modules to reduce size of the overall Python package.
Basically, a new package is introduced, call `python-light`,
and everything that's extra (or big) is put in other packages.
The `python` package becomes a metapackage that installs `python-light`
along with the rest of the packages.
Base work started by Jan Čermák.
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This module is not necessary in OpenWrt because the functionality it
provides (i.e. installation of setuptools and PIP) is ensured by
python-pip and python-setuptools packages.
See: https://docs.python.org/2.7/library/ensurepip.html
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Python packs some pip installation script during the build,
which looks like a better idea to use for the python-pip
and/or python-setuptools packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Some symbols are not found (tgetnum and BC).
Looks like the termcap lib, which should be in libncurses(w)
but maybe some build param would be required.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Redefine python-full as all-pages-minus-a-few-that-don't make sense.
Remove all other packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This fix is quite critical since it fixes copying the libpython shared lib.
The previous source folder we've used is ok, it has the shared lib,
but libpython2.7.so is not a symlink of libpython2.7.so.1.0, but
rather a copy of it.
Which means that libpython2.7.so takes twice as much space
on the target's flash.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python's build scripts prefer ncursesw, and if it is detected
it will be used.
The problem will occur when linking, since ncursesw libs may not be
installed if not added as deps, but the sources will be compiled
against ncursesw.
Reference from Python's HISTORY file:
Patch #1428494: Prefer linking against ncursesw over ncurses library.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This will reduce the bloat when users will want to compile in their
Python C extensions.
There will be a initial bloat (several kb) if just Python
is installed, but that will be compensated when users will add more
C extensions.
During the build we also have to add Python's PKG_BUILD_DIR
so that the shared lib is found when compiling Python's
built-in C extensions.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
