Well, they're not yet compiled, but in the next commit
they should be.
People have been complaining [citation needed] to me
via email or via Github that Python's performance is crap
because it packages sources directly and they're not compiled.
And Python has to compile the sources on each run, and
on-the-fly.
Allowing compilation caching is also a no-no, because
I'll get complaints that the flash storage fills up
whenever a Python app runs.
So, to give the user a choice, the new de-facto packaging
for Python packages will be:
* ship compiled + [ preferably ] optimized files
* package sources separately
The problem is that this doubles the number of packages
in LEDE/OpenWrt, but build-times should not suffer a big
hit, since the compilation is done once, and the
install phase should not be too intensive.
Oh, and people don't need ship source packages if
they don't want to.
To do that, a packager needs to just call
`$(eval $(call BuildPackage,python-<package>-src))`
The `python-` prefix is important.
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>
For consistency, use full name instead of $(PKG_NAME) in define and eval
lines for all packages.
I've seen reviews that asked to do this before, and I am asking the same
during reviews now. To avoid this in the future, fix this treewide so
when people use existing packages as example, we will not have to
request this change anymore.
This makes all packages consistent with both LEDE and OpenWrt base
repositories.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
python-cryptography tries to install other packages during setup.
However, this isn't needed, since they should have been already
resolved/installed via LEDE/OpenWrt's build system dep logic.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
It's not 100% aligned with the ncurses' definition.
Reported-by: Arturo Rinaldi <arturo@arduino.org>
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
After removing python-setuptools package, the dependency
chain to python/host is a bit different.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Import a proposed upstream bug fix to allow building against recent curl
versions. Fixes the following error observed by the buildbots:
curlopt-constants.c:129:49: error: 'CURL_STRICTER' undeclared (first use in this function)
if (strEQ(name, "STRICTER")) return CURL_STRICTER;
Upstream bug: https://rt.cpan.org/Public/Bug/Display.html?id=117793
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
There might be no ABI breakage when the first two number
of version are the same.
(No change on generated packages. No need to bumb release)
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
So, I chose to workaround it in the Makefile.
A proper fix is a bit more work that I would like to do now,
and I have no suggestion/idea for a good fix right now.
The problem is with the `CMD` part that's used in the install rule,
together with the fact that PREFIX is the same as the source location.
```
CMD="find . -maxdepth 1 -mindepth 1 \( -name '*.py' -not -name 'test_*' -not -name 'setup.py' \) -or \( -type d -not -name 'dist' -not -name '*.egg-info' -not -name '__pycache__' \)| xargs --no-run-if-empty cp -r -t $(PREFIX)"
```
The gist of it, is that it seems that this will filter
and copy to `PREFIX` all python sources and folders that
are not names `dist`, `__pycache__`, or `*.egg-info`.
And it searches all folders at (exactly) depth 1.
The solution I chose is to put a `dist` folder under
`_install_tmp`, which is kind of a trick to go
to depth 2 and avoid both conditions in the `find` call.
This avoids errors:
```
cp: './weakref.py' and '/home/sandu/work/lede/build_dir/target-mips_24kc_musl-1.1.16/micropython-lib-1.8.6-f81e979c56dddb771ad36ec381b7f2c6cd12111f-f81e979c56dddb771ad36ec381b7f2c6cd12111f/_install_tmp/weakref.py' are the same file
cp: './xmltok.py' and '/home/sandu/work/lede/build_dir/target-mips_24kc_musl-1.1.16/micropython-lib-1.8.6-f81e979c56dddb771ad36ec381b7f2c6cd12111f-f81e979c56dddb771ad36ec381b7f2c6cd12111f/_install_tmp/xmltok.py' are the same file
cp: './zipfile.py' and '/home/sandu/work/lede/build_dir/target-mips_24kc_musl-1.1.16/micropython-lib-1.8.6-f81e979c56dddb771ad36ec381b7f2c6cd12111f-f81e979c56dddb771ad36ec381b7f2c6cd12111f/_install_tmp/zipfile.py' are the same file
```
Initially I tried to add exit 0, but that would
just hide other (potentially worse) issues.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Certain strings are misinterpreted as comments by perlmod.mk and removed
when they shouldn't be (in particular, perl-cgi). Enable this whenever
you have sufficient flash space.
Globally, CONFIG_PERL_NOCOMMENT=y (default) causes comments to be stripped
as before. However, a package (like perl-cgi) can override this with
PKG_LEAVE_COMMENTS=1.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
This fixes the following build error, spotted by the LEDE buildbots:
{standard input}: Assembler messages:
{standard input}:557: Error: operand 3 should be an integer register -- `mul x0,x0,1048576'
{standard input}:558: Error: operand 3 should be an integer register -- `smulh x1,x0,1048576'
Makefile:1466: recipe for target 'ext/opcache/zend_accelerator_module.lo' failed
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
The macro perlmod/Install does comment stripping which gets confused by
the line:
in several files in this module, incorrectly deleting it as a comment.
It's not: it's the closure of a "= q/" literal.
See PR #3740 as this is a prerequisite.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
LEDE now provides libncursesw by default [even for libncurses].
No need to keep this patch around.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Python comes with it's own builtin libffi lib, which
seems easier to use for the host build, than trying
to use the one from the package feeds.
Also, dropping `005-fix-libffi-x86-64-configure.patch`
Not needed anymore.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
I just found out that, that the BUILD_VARIANT var
is not set for the host build, so technically this code
would never get used.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>