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? |
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
2 times, most recently
from
4e2cdc8 to
fc09e90
Compare
|
Rebase done |
| # Sample job (that failed): https://github.com/nodemcu/nodemcu-firmware/actions/runs/17306868602/job/49131917376#step:3:153 | ||
| # => disable the Windows jobs for now | ||
|
|
||
| # build_luac_cross_win: |
There was a problem hiding this comment.
First let me apologize for not coming back to this PR earlier.
The Idea of merging the commit of @marcelstoer was to leave the commented out part in, so it can be fix later to also build with VisualStudio. Your new build method should be separate.
Possibly with your changes concerning the header It will also be possible to move the VisualStudio Build to a newer version.
There was a problem hiding this comment.
Done, now the commits won't mess with the commented out windows builds.
There was a problem hiding this comment.
shouldn't these files be taken from the toolchain?
Or if the toolchain does not have the files, at least be included after the toolchain version (and then effectively be ignored due to the include guard)
There was a problem hiding this comment.
Hi @HHHartmann , I think this will already work, because the search order is the same order of the -I flags, as SDK includes are included right after the SDK_overrides, they will be the default, unless not found then it will search the other paths. As I could see from commands here, it looks like the app/include is the last PATH to be searched.
xtensa-lx106-elf-gcc -I ../../sdk-overrides/include -I /home/caioh/src/nodemcu-firmware/sdk/esp_iot_sdk_v3.0-e4434aa/include -D_C_TYPES_H_ -O2 -ffunction-sections -fno-jump-tables -fdata-sections -fpack-struct=4 -Wno-error=implicit-function-declaration -Dstricmp=strcasecmp -DWIN32 -g -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -DESP_INIT_DATA_DEFAULT="\"/home/caioh/src/nodemcu-firmware/sdk/esp_iot_sdk_v3.0-e4434aa/bin/esp_init_data_default_v05.bin\"" -DLWIP_OPEN_SRC -std=gnu11 -Wimplicit -I ../libc -I ../lua -I ../platform -I ../spiffs -I ../ -I ../include -o .output/eagle/debug/obj/user_main.o -c user_main.c
The -I ../include is the least priority here when I run make -n to check.
caiohamamura
force-pushed
the
windows_compilation
branch
from
fc09e90 to
25f157e
Compare
caiohamamura
force-pushed
the
windows_compilation
branch
from
25f157e to
3ddf172
Compare
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.