There are some scripts used when building micropython that require
python3 on the build host. Use BR2_PYTHON3_HOST_DEPENDENCY so this can
be either be satisfied by installing it on the build host or by building
the host-python3 package.
Fixes:
- http://autobuild.buildroot.net/results/b85b2214576030026a8e04d142a77a2648379417/
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Drop patch and set GIT_DIR as suggested by upstream during review of an
upstreamable solution, see
https://github.com/micropython/micropython/pull/5002
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bring in the latest version and remove patch that has been applied upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
On Github, a large number of projects name their tag vXYZ (i.e v3.0,
v0.1, etc.). In some packages we do:
<pkg>_VERSION = v0.3
<pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION))
And in some other packages we do:
<pkg>_VERSION = 0.3
<pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION))
I.e in one case we consider the version to be v0.3, in the other case
we consider 0.3 to be the version.
The problem with v0.3 is that when used in conjunction with
release-monitoring.org, it doesn't work very well, because
release-monitoring.org has the concept of "version prefix" and using
that they drop the "v" prefix for the version.
Therefore, a number of packages in Buildroot have a version that
doesn't match with release-monitoring.org because Buildroot has 'v0.3'
and release-monitoring.org has '0.3'.
Since really the version number of 0.3, is makes sense to update our
packages to drop this 'v'.
This commit only addresses the (common) case of github packages where
the prefix is simply 'v'. Other cases will be handled by separate
commits. Also, there are a few cases that couldn't be handled
mechanically that aren't covered by this commit.
Signed-off-by: Victor Huesca <victor.huesca@bootlin.com>
[Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite,
python-scapy3k, softether]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(With correct formatting now)
The build step now requires building mpy-cross first.
Signed-off-by: Blomme, Maarten <Maarten.Blomme@flir.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit fixes the warnings reported by check-package on the help
text of all package Config.in files, related to the formatting of the
help text: should start with a tab, then 2 spaces, then at most 62
characters.
The vast majority of warnings fixed were caused by too long lines. A
few warnings were related to spaces being used instead of a tab to
indent the help text.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check-package script when ran gives warnings on ordering issues
on all of these Config files. This patch cleans up all warnings
related to the ordering in the Config files for packages starting with
the letter m in the package directory.
The appropriate ordering is: type, default, depends on, select, help
See http://nightly.buildroot.org/#_config_files for more information.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The install step now requires CROSS_COMPILE as some C files are
generated at install time. Also remove patches that have been applied
upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The fix from commit 26248571b6 ("micropython: fix build failures") was
applied upstream. This replaces the local buildroot fix with the patch
that was accepted upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There are two problems building micropython for Blackfin. The first is
some printf format specifier warnings/errors that seem to be triggered
only for that architecture/compiler. This could be worked around by
specifying CFLAGS=-Wno-error=format.
The second problem is that libffi doesn't provide the closure
implementation on Blackfin. There is no known workaround for this issue.
For now disable micropython on Blackfin.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Rather than specifying architectures that do not have explicit support
in micropython invert the logic and set MICROPY_GCREGS_SETJMP=1 if the
architecture does not have explicit support. MIPS is listed as being
supported but this support consists of automatically defining
MICROPY_GCREGS_SETJMP 1 based on __mips__ being defined.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch applies an upstream patch to fix a compile error like this
one:
modffi.c: In function 'ffifunc_call':
modffi.c:358:25: error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast]
values[i] = (ffi_arg)a;
This error can be highlighted when building micropython for MIPS64 n32
because ffi_arg is 64-bit wide and the pointers on MIPS64 n32 are 32-bit
wide, so it's trying to case an integer to a pointer (or vice versa) of
a different size. We should cast first the pointer (or the integer) to a
pointer sized integer (intptr_t) to fix that problem.
This patch was merged upstream as a result of this pull request:
https://github.com/micropython/micropython/pull/1471
Fixes:
http://autobuild.buildroot.net/results/e22/e2253de3f96e9a53e75b4cecaf56c1df2950803f/
[Thomas: use a single assignement for MICROPYTHON_PATCH.]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes the following error when building for a 64-bit target
../py/objint_mpz.c:54:5: error: right shift count >= width of type [-Werror]
(MP_SSIZE_MAX >> MPZ_DIG_SIZE * 4) & DIG_MASK,
^
../py/objint_mpz.c:54:5: error: initializer element is not constant
../py/objint_mpz.c:54:5: error: (near initialization for 'maxsize_dig[4]')
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
These architectures don't have explicit exception handling support in
micropython but can use the setjmp fallback behaviour instead.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Micro Python is a lean and fast implementation of the Python 3
programming language that is optimised to run on a microcontroller.
[Thomas: fix minor typo in Config.in noticed by Vicente.]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
