This saves time when building on Travis CI: unconditionally fetching all
submodules takes about 40 seconds, but not all are needed for any given
port, so only fetch as necessary.
This change brings the following benefits:
- all existing tests and test behaviour is be retained
- can now use Travis parallel build mechanism
- total time for tests is about 5 mins 30 secs, down from around 10 mins
- two additional test suites are now run: standard (non coverage) unix
build and nanbox unix build
- much easier to see what is failing: if you click through to the Travis CI
details each parallel build job is displayed with pass/fail
- scales much better when adding new test targets
Coveralls requires a "recent" version of urllib3, whereas requests requires
a "not so recent" version, less than 1.23. So force urllib3 v1.22 to get
it all working.
Previously, testing of stackless build happened (manually) in
travis-stackless branch. However, stackless offers important
featureset, so it's worth to test it as a part of the main
CI. Strict stackless is used because it's the "real" stackless
build, which avoids using C stack as much as possible (non-strict
just prefers heap over C stack, but may end up using the latter).
This allows to test the PYBV11 target as well as the network drivers
without adding another rule. It also removes the need to use -B,
side-stepping the issue of whether or not -B works with qstr auto
generation.
The STM32 F7 and L4 boards use significantly different code to the F4
boards so it's important to test them with CI. To keep CI build times
within a reasonable limit the STM32F4DISC board is no longer built, it's
anyway very similar to the standard F4 build for PYBv1.0.
This is actually long overdue: the README in the windows directory has been
updated once to indicate mingw32 is abandoned and not ok to use with uPy,
but we forgot travis builds were still using it.
As a bonus the travis build will succeed again since moduerrno.c now compiles.
(see https://github.com/micropython/micropython/pull/2399)
There appears to be issue signature problem with the PPA package we use,
so workaround it this way for now. Warning: with broken signature, there's
always a possibility that PPA was hacked and ships trojaned binaries.
For some reason, Travis now has Google Chrome PPA included in the builder
image, that lacks i386 arch, that leads to apt-get update error. So, ignore
it (this is not ideal as may lead to actual repo update failures to be missed,
leading to installation of old package, leading to weird errors; let's keep
that in mind).
unix-cpy was originally written to get semantic equivalent with CPython
without writing functional tests. When writing the initial
implementation of uPy it was a long way between lexer and functional
tests, so the half-way test was to make sure that the bytecode was
correct. The idea was that if the uPy bytecode matched CPython 1-1 then
uPy would be proper Python if the bytecodes acted correctly. And having
matching bytecode meant that it was less likely to miss some deep
subtlety in the Python semantics that would require an architectural
change later on.
But that is all history and it no longer makes sense to retain the
ability to output CPython bytecode, because:
1. It outputs CPython 3.3 compatible bytecode. CPython's bytecode
changes from version to version, and seems to have changed quite a bit
in 3.5. There's no point in changing the bytecode output to match
CPython anymore.
2. uPy and CPy do different optimisations to the bytecode which makes it
harder to match.
3. The bytecode tests are not run. They were never part of Travis and
are not run locally anymore.
4. The EMIT_CPYTHON option needs a lot of extra source code which adds
heaps of noise, especially in compile.c.
5. Now that there is an extensive test suite (which tests functionality)
there is no need to match the bytecode. Some very subtle behaviour is
tested with the test suite and passing these tests is a much better
way to stay Python-language compliant, rather than trying to match
CPy bytecode.
The function and corresponding command-line option are only enabled for
the coverage build. They are used to exercise uPy features that can't
be properly tested by Python scripts.
The port currently implements support for GPIO, RTC, ExtInt and the WiFi
subsystem. A small file system is available in the serial flash. A
bootloader which makes OTA updates possible, is also part of this initial
implementation.
Jim Mussared
Damien George
Paul Sokolovsky
stijn
danicampora