Seems that the Python C extensions were being
(or at least trying to be) build using '/usr/include' as the first
include folder.
Seems this issue was already fixed on MacOS X and now we've extended
it for our case.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that this allows some goofs, because some files
silently do not get copied and the build succeeds, even though
it shouldn't.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that if you add a package folder this would also
include the compiled python3 files which increases fw size.
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 mostly helps to avoid confusion when modules are cross-compiled.
Otherwise build folders are named with the host's platform name.
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>
The target's PYTHON_INC_DIR should take precedence over the host's
include dir when cross-compiling.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that the Python C extensions were being
(or at least trying to be) build using '/usr/include' as the first
include folder.
Seems this issue was already fixed on MacOS X and now we've extended
it for our case.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that this allows some goofs, because some files
silently do not get copied and the build succeeds, even though
it shouldn't.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Seems that if you add a package folder this would also
include the compiled python files which increases fw size.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
And also remove all other references to avoid confusion.
libnsl isn't really needed. Removing it allows glibc based
toolchains to build perl.
Signed-off-by: Marcel Denia <naoir@gmx.net>
Type signedness is undefined for char. char may actually be unsigned for
some CPUs.
This fixes various bugs on PPC, like negative array indices.
Signed-off-by: Marcel Denia <naoir@gmx.net>
According to PEP394 (http://legacy.python.org/dev/peps/pep-0394/)
the 'python' command should refer to 'python2'.
In our case, this means we should reboot the old python package.
We could rename the package name to python2, but that would
just complicate things a bit with other packages, and
since we're doing this reboot, such a complication would be
unnecessary.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
ruby-core is problematic as it is too big.
It is impossible to fix pkgs dependencies as
ruby-core would generate multiple cycled dependencies
between packages.
Also, "core" in ruby context means "classes that does not need a 'require'".
This is not the case of ruby-core classes. They are, actually, a subset of
Ruby Standard Library.
In every detected case where a portion of ruby-core could be isolated and
save another pkgs from requiring all ruby-core where spin-off into a new
subset. Also, big portions of ruby-core, not require by current ruby-* pkgs
where spin-off in new pkgs. The remaining of ruby-core was put into a new ruby-misc.
ruby-stdlib was created as a meta package that requires all ruby packages that are
part of Ruby Standard Library. For a full Ruby Standard Library, just install
ruby-stdlib and its deps.
Created pkgs from ruby-stdlib:
- ruby-misc
- ruby-csv
- ruby-datetime
- ruby-dbm
- ruby-debuglib
- ruby-drb
- ruby-fiddle
- ruby-filelib
- ruby-logger
- ruby-math
- ruby-multithread
- ruby-mkmf
- ruby-net
- ruby-optparse
- ruby-patterns
- ruby-prettyprint
- ruby-pstore
- ruby-racc
- ruby-rbconfig
- ruby-rinda
- ruby-ripper
- ruby-sdbm
- ruby-shell
- ruby-socket
- ruby-uri
Some files from ruby-openssl where moved to new subpkgs (as ruby-net and ruby-drb).
All dependencies where redefined based on auxiliar script ruby_find_pkgsdeps
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Some files that belong to other subpkgs where still in
ruby-core. Just moved them to the correct place.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Ruby encoding library was too big and bring unecessary encodings for a simple ruby usage.
All not directly required encodings from stdlib where moved to ruby-enc-extra.
Created pkg from ruby-enc
- ruby-enc-extra (from ruby-enc)
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
ruby_find_pkgsdeps: look for file dependencies (checks
require and Encoding references) and extrapolate it to pkgs
deps. Also checks whether a dep is redundant or missing in pkgs.
Must run inside an OpenWRT with all ruby* pkgs installed.
ruby_missingfiles: list files in staging/target and from files
comparing side by side its contents. It helps to easly visualize
which file is not packaged in an ipk.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Digest can use OpenSSL or ruby internal implementation of hash functions. The first
uses less disk space but requires openssl, that is relatively big. As internal hash
implementations are not too much bigger than openssl version, it is compiled by
default. A new config option can change it to use OpenSSL instead.
As digest is independent from openssl, ruby-digest was created as a new pkgs.
Adds pkgs:
- ruby-digest (from ruby-openssl)
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Some ruby gems where still in ruby-core pkg. These files where
moved outside ruby-core into ruby-gems or their own subpkg.
ruby-unit renamed to ruby-testunit as its gem is named test-unit.
ruby-rdoc left a file in ruby-core.
Psych is a gem and deserves its own subpkg. It replaces syck
(used by yaml) on recent ruby version (ref:
https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/36786)
Also, some psych files where packed incorrecly into ruby-json. The asterisk
in */json was intend to match <arch>/json/ and not psych/json.
Files where derived
from ruby-core and a lost file in ruby-json.
New subpkgs:
- ruby-bigdecimal
- ruby-io-console
- ruby-minitest
- ruby-psych
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
ext/digest/rmd160 was referencing a function that never existed in openssl.
The name was simply mistyped. Now it can use openssl.
openssl was always linked to ext/digest when library is avaiable,
even when it was disable by configure option and not used by code.
upstream refs: https://bugs.ruby-lang.org/issues/10252
upstream refs: https://bugs.ruby-lang.org/issues/10324
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
minitest can live without gems. Just a minor fix to
solve a require that fails when gem is missing
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
rdoc seems to be written to run without gem. However,
some internal code still does not check for gems presence.
With a small patch, rdoc can run without gems.
Ref: https://bugs.ruby-lang.org/issues/10196
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>