Not sure how it can happen that the files are not
installed via the host build.
Maybe some SDK-like build.
Let's make sure they are installed via InstallDev rule too.
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>
If there is only Python bytecodes, then
the __init__.py script will be concatenated, and
the __init__.pyc as well.
This is becase this bit `path = os.path.join(path, '__init__'+extension)`
is iterated twice.
This is a bug in Python3, also because we ship bytecodes
instead of source code [ with Python & Python3 ].
Python is not affected.
Reported-by: Mirko Vogt <mirko@nanl.de>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This is in essence fixes pip3.
That means pip3 will ship without Python byte-codes
for a while, until I'll find a better way to fix it.
I couldn't think of a not-very hack-ish way of doing it.
The only draw-back of this, will be that pip3 will run
a bit slower ; but that should be ok for a while.
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>
Well, this slipped by for some time.
This should make the Python core packages even more lighter.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Technically, this just updates build details.
No functionality change to package itself.
So, no need to increase PKG_RELEASE on this change.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python 3.6 comes with some new cross-compilation logic that
generates filenames/paths with arch, abiflags and mach
included (in filename & path).
Problem is that the generated paths/filenames are not
consistent across archs (noticed on x86_64 & ar71xx),
so patch `016-adjust-config-paths.patch` was added
to mitigate this (by removing extra stuff in paths).
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And move \`python3-package.mk\` include, same as in python package.
This is mostly to have consistency/similarity between python & python3
packages.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
--sysconfigdir and --sbindir are obtained from --prefix
and --exec-prefix, so no need to have them explicitly
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Also, override all prefix args in the HOST_CONFIGURE_ARGS
so that this works fine on CC/15.05.
There are some changes in core regarding package builds that
require this.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python 3 prefers usage of wcsftime() over strftime() if it's available,
however this function returns just an empty string in some older
uClibc versions. Proposed solution disables detection of wcsftime() in
./configure that results in HAVE_WCSFTIME being undefined, effectively
disabling branches of code that use possibly broken wcsftime().
See: http://lists.busybox.net/pipermail/uclibc/2014-November/048718.html
Signed-off-by: Jan Čermák <jan.cermak@nic.cz>
Some notes about the 'encodings' module, which is about 1.7 MB.
Unfortunately that one cannot be moved into the 'python3-codecs'
package, because Python tries to load up all available encodings
at startup.
Some efforts to add a dummy folder/python file have failed so far,
since there's a C code (Python/codecs.c) that tries to evaluate that
all encodings (in the encodings folder/module) are valid.
Basically the encodings module is a repository of encodings,
and it seemst there are quite a few of them.
Maybe a request to upstream Python would work for this, to
make encodings a bit more decoupled from the interpreter.
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>
Alexandru Ardelean
Matthias Schiffer
Felix Fietkau
Florian Fieber
Jan Čermák
Nicolas Thill
Alexandru Ardelean