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.
mp_compile no longer takes an emit_opt argument, rather this setting is now
provided by the global default_emit_opt variable.
Now, when -X emit=native is passed as a command-line option, the emitter
will be set for all compiled modules (included imports), not just the
top-level script.
In the future there could be a way to also set this variable from a script.
Fixes issue #4267.
mpy-cross is a host, not target binary. It should not be build with the
target compiler, compiler options and other settings. For example,
If someone currently tries to build from pristine checkout the unix port
with the following command:
make CROSS_COMPILE=arm-linux-gnueabihf-
then mpy-cross will be built with arm-linux-gnueabihf-gcc and of course
won't run on the host, leading to overall build failure.
This situation was worked around for some options in 1d8c3f4cff, so add
MICROPY_FORCE_32BIT and CROSS_COMPILE to that set too.
mpy-cross doesn't depend on any code in the extmod directory so completely
exclude it from the build (extmod may still be scanned for qstrs but that
is controlled by py/py.mk). This speeds up the build a little, and
improves abstraction of this component.
Also, make -I$(BUILD) take precedence over -I$(TOP) in case there are stray
files in the root directory that would be picked up.
Header files that are considered internal to the py core and should not
normally be included directly are:
py/nlr.h - internal nlr configuration and declarations
py/bc0.h - contains bytecode macro definitions
py/runtime0.h - contains basic runtime enums
Instead, the top-level header files to include are one of:
py/obj.h - includes runtime0.h and defines everything to use the
mp_obj_t type
py/runtime.h - includes mpstate.h and hence nlr.h, obj.h, runtime0.h,
and defines everything to use the general runtime support functions
Additional, specific headers (eg py/objlist.h) can be included if needed.
fmode.c should only be included for builds targetting 'pure' windows, i.e.
msvc or mingw builds but not when using msys or cygwin's gcc (see #2298).
Just checking if the OS is windows and UNAME doesn't have msys stil leaves
the gate open for builds with cygwin's gcc since UNAME there is e.g.
CYGWIN_NT-6.1-WOW.
Fix this by checking for 'mingw' explicitly in the compiler version; both
gcc and clang have the -dumpmachine flag so the check should be ok for
all platforms.
Prior to making this a config option it was previously available on these
(and all other) ports, and it makes sense to keep it enabled for mpy-cross
as well as ports that have a decent amount of space for the code.
The -ansi flag is used for C dialect selection and it is equivalent to -std=c90.
Because it goes right before -std=gnu99 it is ignored as for conflicting flags
GCC always uses the last one.
This type was used only for the typedef of mp_obj_t, which is now defined
by the object representation. So we can now remove this unused typedef,
to simplify the mpconfigport.h file.
When compiling with msys2's gcc there's no need to apply the binary fmode
so adjust the Makefile to reflect that.
When compiling with mingw we need to include malloc.h since there is no
alloca.h, and the 64bit detection in mpconfigport.h needs some adjustment.
This is a fix for https://github.com/micropython/micropython/issues/2209:
by default a file created using open() uses text translation mode so writing
\n to it will result in the file having \r\n. This is obviously problematic
for binary .mpy files, so provide functions for setting the open mode
and use binary mode in mpy-cross' main().
.mpy files contain the name of the source file that they were compiled
from. This patch adds a way to change this name to an arbitrary string,
specified on the command line with the -s option. The default is to use
the full name of the input filename.
This new -s option is useful to strip off a leading directory name so
that mpy-tool.py can freeze packages.
Building in 32-bit mode was only to reduce binary size on 64-bit machines
and is otherwise not needed. Having it forced to 32-bit meant an
unnecessary dependency on 32-bit libraries that is now removed.
Damien George