Open danngreen opened 1 year ago
As a heads up, the latest firmware commit is failing project creation on Windows due to missing quotes. In Makefile I had to add quotes around Unix Makefiles:
# Detect MinGW and use Make
ifdef SYSTEMROOT
GEN := "Unix Makefiles"
else
GEN := Ninja
endif
Aha, good catch! I think the quotes got lost along the way (and we don't have CI for windows building firmware yet) Do you want to make a PR, or I'm happy to do it?
https://github.com/4ms/metamodule/pull/86
I just submitted the pull request. I'm sorry, I didn't realize that it would trigger a CI build just via that.
Thanks!
In the
firmware-cmake
branch, on my minimal windows 11 + MSYS + MinGW64 setup, it will build fine if I use cmake to generate Makefiles:But if I use Ninja like this:
...then I get some strange errors, which I haven't found a solution to. The errors happen during build steps that were generated from cmake
add_custom_command
andadd_custom_target
commands. These run commands in the terminal, and I suspect there's some sort of slash issue, or character escaping, or shell-wrapping issue happening. Example (verbose output shown withcd build && ninja -v -j 1
:That one is from running the unit test via an external Makefile. I'm noticing use of forward and back slashes, and also the wrapping of the
make
command within acmd.exe /C "cd /D C:\(path) ..."
wrapper. The commands run fine if I manually run them verbatim, but without this wrapper.If I skip building the tests, I still get errors when doing the POST_BUILD steps after linking the main_m4.elf:
Huge wall of text, but it also has both types of slashes, and starts with the same cmd.exe wrapper, and even has another nested
cmd.exe /C "cd /D..."
wrapper inside the first one.The work-around I came up with is to make Unix Makefiles the default build system if MinGW is detected. This is done in the firmware Makefile (which has shortcuts for conveniently running the cmake commands) I'll also add this info to the docs.