299bc62586
The code conventions suggest using header guards, but do not define how those should look like and instead point to existing files. However, not all existing files follow the same scheme, sometimes omitting header guards altogether, sometimes using non-standard names, making it easy to accidentally pick a "wrong" example. This commit ensures that all header files of the MicroPython project (that were not simply copied from somewhere else) follow the same pattern, that was already present in the majority of files, especially in the py folder. The rules are as follows. Naming convention: * start with the words MICROPY_INCLUDED * contain the full path to the file * replace special characters with _ In addition, there are no empty lines before #ifndef, between #ifndef and one empty line before #endif. #endif is followed by a comment containing the name of the guard macro. py/grammar.h cannot use header guards by design, since it has to be included multiple times in a single C file. Several other files also do not need header guards as they are only used internally and guaranteed to be included only once: * MICROPY_MPHALPORT_H * mpconfigboard.h * mpconfigport.h * mpthreadport.h * pin_defs_*.h * qstrdefs*.h |
||
|---|---|---|
| .. | ||
| msvc | ||
| .appveyor.yml | ||
| .gitignore | ||
| Makefile | ||
| README.md | ||
| fmode.c | ||
| fmode.h | ||
| init.c | ||
| init.h | ||
| micropython.vcxproj | ||
| mpconfigport.h | ||
| mpconfigport.mk | ||
| realpath.c | ||
| realpath.h | ||
| sleep.c | ||
| sleep.h | ||
| windows_mphal.c | ||
| windows_mphal.h | ||
README.md
This is the experimental, community-supported Windows port of MicroPython. It is based on Unix port, and expected to remain so. The port requires additional testing, debugging, and patches. Please consider to contribute.
Building on Debian/Ubuntu Linux system
sudo apt-get install gcc-mingw-w64
make CROSS_COMPILE=i686-w64-mingw32-
If for some reason the mingw-w64 crosscompiler is not available, you can try mingw32 instead, but it comes with a really old gcc which may produce some spurious errors (you may need to disable -Werror):
sudo apt-get install mingw32 mingw32-binutils mingw32-runtime
make CROSS_COMPILE=i586-mingw32msvc-
Building under Cygwin
Install following packages using cygwin's setup.exe:
- mingw64-i686-gcc-core
- mingw64-x86_64-gcc-core
- make
Build using:
make CROSS_COMPILE=i686-w64-mingw32-
Or for 64bit:
make CROSS_COMPILE=x86_64-w64-mingw32-
Building using MS Visual Studio 2013 (or higher)
In the IDE, open micropython.vcxproj and build.
To build from the command line:
msbuild micropython.vcxproj
Stack usage
The msvc compiler is quite stack-hungry which might result in a "maximum recursion depth exceeded" RuntimeError for code with lots of nested function calls. There are several ways to deal with this:
- increase the threshold used for detection by altering the argument to
mp_stack_set_limitinunix/main.c - disable detection all together by setting
MICROPY_STACK_CHECKto "0" inwindows/mpconfigport.h - disable the /GL compiler flag by setting
WholeProgramOptimizationto "false"
See issue 2927 for more information.
Running on Linux using Wine
The default build (MICROPY_USE_READLINE=1) uses extended Windows console
functions and thus should be ran using the wineconsole tool. Depending
on the Wine build configuration, you may also want to select the curses
backend which has the look&feel of a standard Unix console:
wineconsole --backend=curses ./micropython.exe
For more info, see https://www.winehq.org/docs/wineusr-guide/cui-programs .
If built without line editing and history capabilities
(MICROPY_USE_READLINE=0), the resulting binary can be run using the standard
wine tool.