Epsilon: Issues building the simulator on Windows

[jacobly0]

I ran into a bunch of issues when trying to build the simulator on windows:

• Full dependency list for a clean msys2 install, which should be updated in the sdk docs:
  
  
  
  • 32-bit: pacman -S mingw-w64-i686-gcc mingw-w64-i686-freetype mingw-w64-i686-fltk git make bison python
  
  
  • 64-bit: pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-freetype mingw-w64-x86_64-fltk git make bison python
  
  
• There should be a native msys/mingw toolchain that has SFLAGS = -D_USE_MATH_DEFINES and EXE = exe yet uses the native gcc or clang.
• In the liba bridge, it tests __GLIBC__ to add strlcpy, but windows needs the same thing.
  
  
  
  • As far as I can tell, only BSD and BSD support libraries have strlcpy.
  
  
• On windows, alloca is defined in malloc.h instead of alloca.h.
  
  
  
  • A liba bridge include could be used to redirect alloca.h to malloc.h on windows and the next alloca.h elsewhere.
  
  
• python/src/py/nlrx86.c just doesn't compile on 32-bit windows, but this is possibly an upstream issue.

[gpotter2]

I personally used BashOnWindows (WSL) of windows 10, then followed the same instructions as for linux.
(using an XServer)

[Ecco]

Nice solution @gpotter2 . WSL is definitely a good idea, but the upside of using msys2 is that you get a binary that can be distributed and ran on a vanilla Windows system.

[gpotter2]

Edit: this is outdated

@Ecco Yeah, but I had trouble getting it to work :/
The online sdk windows doc is poor and incomplete, here's how it should looks like:

1. using pacman -S python installs python 3. Numworks will poorly crash on the from sets import Sets (which is not available on python 3). This has been already reported (and ignored) in https://github.com/numworks/epsilon/issues/197. It means we need python 2. In that case use pacman -S python2.
2. But then the executable is python2.exe. Again, numworks won't detect it and crash on it. It means we need to manually add a symbolic link: ln -s /usr/bin/python2.exe /usr/bin/python.exe

To conclude:

pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-freetype mingw-w64-x86_64-fltk git make bison python2
ln -s /usr/bin/python2.exe /usr/bin/python.exe
export PATH=/mingw64/bin:$PATH

And Even with all of this done, you will still get:

gpotter@ZALMAN MSYS /z/Coding/github/epsilon
$ make PLATFORM=simulator clean
CLEAN

gpotter@ZALMAN MSYS /z/Coding/github/epsilon
$ make PLATFORM=simulator
HOSTCC  kandinsky/fonts/rasterizer
RASTER  kandinsky/src/small_font.h kandinsky/src/small_font.c
RASTER  kandinsky/src/large_font.h kandinsky/src/large_font.c
FLEX    poincare/src/expression_lexer.cpp poincare/src/expression_lexer.hpp
BISON   poincare/src/expression_parser.cpp poincare/src/expression_parser.hpp
poincare/src/expression_parser.y: avertissement: 7 conflits par réduction/réduction [-Wconflicts-rr]
QSTRDAT python/port/genhdr/qstrdefs.generated.h
I18N    apps/i18n.cpp
Error: Invalid line "Apps = "Anwendungen"
"
make: *** [apps/Makefile:81: apps/i18n.cpp] Error 255

[Ecco]

This is mostly solved by #239. I'm not closing this issue just yet because we need to update the documentation. Until then, here's what you need to know:

• Don't install python but mingw-w64-x86_64-python2 with pacman (we need to change the doc)
• Get the latest version (#239 has been merged)
• This only allows you to build the simulator (make PLATFORM=simulator). Building for the device should just be a matter of adding the proper toolchain though, but it doesn't work just yet if you simply follow the instructions.
• It's only been tested on 64bit windows

And, last but not least: it shouldn't break again since we now have a relevant CI step.

[gpotter2]

@Ecco Seems to be working ! Thanks

[Ecco]

It seems like all this has been taken care of. Don't hesitate to reopen issues if you ran into some other bugs!