Allow windows compilation using official espressif toolchain (msys2) #3687
Conversation
|
In addition this will also allow to more throughly test and CI with a windows github action relying in MSYS2. |
caiohamamura
force-pushed
the
windows_compilation
branch
3 times, most recently
from
5d021d2 to
ec95c38
Compare
|
Now I added compilation and tests support for windows using the official toolchainhttps://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/get-started/windows-setup.html. Note: question?Would it be better if we provided a github release for the windows toolchain just in case espressif stop giving support? |
| toolchain: $(TOOLCHAIN_ROOT)/bin $(ESPTOOL) | ||
|
|
||
| $(TOOLCHAIN_ROOT)/bin: $(TOP_DIR)/cache/toolchain-esp8266-$(GCCTOOLCHAIN).tar.xz | ||
| $(TOOLCHAIN_ROOT)/bin: $(TOP_DIR)/cache/toolchain-esp8266-$(GCCTOOLCHAIN).$(TOOLCHAIN_EXT) |
There was a problem hiding this comment.
This seems to be a debugging leftover
caiohamamura
force-pushed
the
windows_compilation
branch
4 times, most recently
from
9c02252 to
5155aa8
Compare
I support that idea. IIRC there are other tools for which (at some point but not anymore?) we kept or keep local copies. |
|
It needs the MSYS2 for compiling, so we need both: |
I just remembered: https://github.com/nodemcu/espressif-sdk-archive As those two Win tools are ~750MB I suggest we add them both to our |
|
Will you create the releases there? Then if you could provide me the links to update this PR. |
|
GitHub doesn't allow artifacts >100MB in repositories without Git LFS. Hence, that repository now uses LFS to track those two files. Their raw location is as follows:
However, the workflow checkout action or similar allow you reference their repository location without hard-coding the raw URL. |
Done, I have updated the urls in both the Makefile and the github action. |
…tion names in windows. - Makefile: allow implicit functions warnings, define stricmp as macro for strcasecmp, define WIN32. - cc.h: check if BYTE_ORDER is not already defined (which is in windows toolchain) - socket.h: Check if timeval.h hasn't already been included before defining the timeval struct - Define __locale_c_type_ptr function, locale/ctype support is not enabled in windows toolchain.
- Previously lwIP_ASSERT expanded to `return;`, which breaks when used inside functions with non-void return types (causing -Werror failures): this patch updates the macro to allow specifying an appropriate return value. - nodemcu_mdns.c: `send_packet`, also had empty returns. While these could be bypassed with `-Wno-error=return-type`, explicitly returning a value is safer and more correct.
- Project Makefile: Fallback $OS in linux to $(UNAME_S) which uses `uname -s` in linux, since $(OS) is specific to windows. - Luac Cross: add .exe when compiling for windows.
caiohamamura
force-pushed
the
windows_compilation
branch
from
e5e7b06 to
4e2cdc8
Compare
caiohamamura
force-pushed
the
windows_compilation
branch
from
4e2cdc8 to
fc09e90
Compare
|
Rebase done |
devbranch rather than for thereleasebranch.docs/*.Summary
This PR improves Windows compilation support for NodeMCU-Firmware by addressing missing headers, inconsistent function names, and toolchain differences between Windows and Linux.
Changes
Makefile:
cc.h:
socket.h:
locale support:
Headers
Building in windows
These fixes allow building NodeMCU-Firmware with the official windows toolchains provided by espressif: https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/get-started/windows-setup.html.
Follow these steps:
git clone https://github.com/caiohamamura/nodemcu-firmware --branch=windows_compilation --depth=1 --recurse-submodules --shallow-submodulescd nodemcu-firmware && makeMotivation
Besides allowing other developers to use Windows for developing and eventually contributing to this repository, I am writing a VSCode/VSCodium extension for developing for nodemcu, allowing to manage the firmware compilation, selection of modules, flashing and compiling/loading lua code. So I need this repository to be compile ready cross-platform wise for the extension to also work cross-platform.