Add the project file to the mpy-cross directory, which is also where the
executable ends up, and change the Appveyor settings to build mpy-cross
with both msvc and mingw-w64 and verify this all works by running tests
with --via-mpy.
If this is not set it might default to calls to open() to use text mode
which is usually not wanted, and even wrong and leading to incorrect
results when loading binary .mpy files.
This also means that text files written and read will not have line-ending
translation from \n to \r\n and vice-versa anymore. This shouldn't be much
of a problem though since most tools dealing with text files adapt
automatically to any of the 2 formats.
Reserve sources.props for listing just the MicroPython core and extmod
files, similar to how py.mk lists port-independent source files. This
allows reusing the source list, for instance for building mpy-cross. The
sources for building the executable itself are listed in the corresponding
project file, similar to how the other ports specify the source files in
their Makefile.
Append to PyIncDirs, used to define include directories specific to
MicroPython, instead of just overwriting it so project files importing this
file can define additional directories. And allow defining the target
directory for the executable instead of hardcoding it to the windows
directory. Main reason for this change is that it will allow building
mpy-cross with msvc.
We want the .vcxproj to be just a container with the minimum content for
making it work as a project file for Visual Studio and MSBuild, whereas the
actual build options and actions get placed in separate reusable files.
This was roughly the case already except some compiler options were
overlooked; fix this here: we'll need those common options when adding a
project file for building mpy-cross.
These were probably added to detect more qstrs but as long as the
micropython executable itself doesn't use the same build options the qstrs
would be unused anyway. Furthermore these definitions are for internal use
and get enabled when corresponding MICROPY_EMIT_XXX are defined, in which
case the compiler would warn about symbol redefinitions since they'd be
defined both here and in the source.
As per PEP 485, this function appeared in for Python 3.5. Configured via
MICROPY_PY_MATH_ISCLOSE which is disabled by default, but enabled for the
ports which already have MICROPY_PY_MATH_SPECIAL_FUNCTIONS enabled.
The C++ standard forbids redefining keywords, like inline and alignof, so
guard these definitions to avoid that, allowing to include the MicroPython
headers by C++ code.
This enables going back to previous wrapped lines using backspace or left
arrow: instead of just sticking to the beginning of a line, the cursor will
move a line up.
During make, makemoduledefs.py parses the current builds c files for
MP_REGISTER_MODULE(module_name, obj_module, enabled_define)
These are used to generate a header with the required entries for
"mp_rom_map_elem_t mp_builtin_module_table[]" in py/objmodule.c
Add some more POSIX compatibility by adding a d_type field to the
dirent structure and defining corresponding macros so listdir_next
in the unix' port modos.c can use it, end result being uos.ilistdir
now reports the file type.
Use overrideable properties instead of hardcoding the use of the
default cl executable used by msvc toolsets. This allows using
arbitrary compiler commands for qstr header generation.
The CLToolExe and CLToolPath properties are used because they are,
even though absent from any official documentation, the de-facto
standard as used by the msvc toolsets themselves.
This patch in effect renames MICROPY_DEBUG_PRINTER_DEST to
MICROPY_DEBUG_PRINTER, moving its default definition from
lib/utils/printf.c to py/mpconfig.h to make it official and documented, and
makes this macro a pointer rather than the actual mp_print_t struct. This
is done to get consistency with MICROPY_ERROR_PRINTER, and provide this
macro for use outside just lib/utils/printf.c.
Ports are updated to use the new macro name.
Printing debugging info by defining MICROPY_DEBUG_VERBOSE expects
a definition of the DEBUG_printf function which is readily available
in printf.c so include that file in the build. Before this patch
one would have to manually provide such definition which is tedious.
For the msvc port disable MICROPY_USE_INTERNAL_PRINTF though: the
linker provides no (easy) way to replace printf with the custom
version as defined in printf.c.
Build and test 32bit and 64bit versions of the windows port using gcc
from mingw-w64. Note a bunch of tests which rely on floating point
math/printing have been disabled for now since they fail.
The number of registers used should be 10, not 12, to match the assembly
code in nlrx64.c. With this change the 64bit mingw builds don't need to
use the setjmp implementation, and this fixes miscellaneous crashes and
assertion failures as reported in #1751 for instance.
To avoid mistakes in the future where something gcc-related for Windows
only gets fixed for one particular compiler/environment combination,
make use of a MICROPY_NLR_OS_WINDOWS macro.
To make sure everything nlr-related is now ok when built with gcc this
has been verified with:
- unix port built with gcc on Cygwin (i686-pc-cygwin-gcc and
x86_64-pc-cygwin-gcc, version 6.4.0)
- windows port built with mingw-w64's gcc from Cygwin
(i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc, version 6.4.0)
and MSYS2 (like the ones on Cygwin but version 7.2.0)
Add some features which are already enabled in the unix port and
default to using the Python stack for scoped allocations: this can be
more performant in cases the heap is heavily used because for example
the memory needed for storing *args and **kwargs doesn't require
scanning the heap to find a free block.
For MSVC off_t is defined in sys/types.h but according to the comment
earlier in mpconfigport.h this cannot be included directly.
So just make off_t the same as mp_off_t.
This fixes the build for MSVC with MICROPY_STREAMS_POSIX_API
enabled because stream.h uses off_t.
This is to keep the top-level directory clean, to make it clear what is
core and what is a port, and to allow the repository to grow with new ports
in a sustainable way.
