Closed emilekm2142 closed 5 years ago
What did I do wrong?
I'm not sure. What path is this repository in, ie what is the value of $(BUILD)?
So there's a few places in the makefile where we use $(BUILD)/$(ESPCOMP)/
as a build directory for the esp-idf files, and I think that maybe what's happening here is that the E:
in the ESPCOMP variable is stuffing that up.
I'll try and test this myself on Win10, but for the moment @emilekm2142 can you please try using paths without drive letters and see if the problem goes away?
It might make more sense for us to always build into $BUILD/esp-idf/
or something ... we can get some very long paths out of the current process and it doesn't behave nicely with relative paths either, eg:
ESPIDF=../../esp-idf/
I've run into exactly the same problem on Windows 10, but I've installed ESP-IDF at C:/msys32/esp/esp-idf
$BUILD is unset. $ESPCOMP is set to be C:/msys32/esp/esp-idf
When I change $ESPCOMP to be just /esp/esp-idf, the build works. (Well, there's another syntax error in dht.py, but that's very likely a different problem.)
I don't understand exactly why it works without the C:/msys32 prefix; I think MSYS/MinGW is doing something tricky.
OK, so I finally got my head around this: that line 209 looks like:
$(BUILD)/$(ESPCOMP)/esp32/dport_access.o: CFLAGS += -Wno-array-bounds
which expands out to something like:
build/E:/esp-idf/components/esp32/dport_access.o: CFLAGS += -Wno-array-bounds
... which make can't properly parse. If you try to make a Makefile rule like:
a:b: c
it gets the same error. Anyway, I'm messing with the build paths to try and fix this up, will PR when I get it working. In the meantime the workaround of having all the directories on the one drive and not using drive letters in paths should be okay
Just to expand on what I mentioned above, I successfully built this on Windows 10 after eliminating the drive letter and flashed it to an ESP32-WROVER-KIT. The only other problem I ran into was that all the symbolic links in the git repository were broken; a bunch of cutting and pasting solved that.
Yeah, the symlinks are a problem for Windows too.
We discussed this at PyConAU and I think maybe we can replace the symlinks with some extra entries in the Makefile, eg: modify tools/make-frozen.py
to take a list of modules as well as directories and then we can have a variable:
FROZEN_MODS = modules/*.py ../py/modules/*.py ../tools/upip.py ../esp8266/modules/onewire.py
and so on and so forth. That way we wouldn't need the symlinks.
(oh, cross-platform builds are so much fun ...)
bit of a proof of concept at https://github.com/nickzoic/micropython-esp32/tree/esp32-142-makefile-poc although its probably not going about it the right way: should make changes to py/mkrules.mk as well I think. But I'll try this on Windows and see if it works first.
I am also working on symlink issue. See PR #3340. I'm back on Windows build issues now, then I will be re-written my symlink solution after discussion with@pfalcon. Goals are:
I intend to keep improving building under Windows as much as possible. I don't yet have a solution for drive letter colon or spaces in paths.
The build system for esp32 has changed quite a bit since this bug was opened, and in particular specifying frozen modules now no longer uses symlinks. So closing. If there's still a problem please report at https://github.com/micropython/micropython
make
gives the following error:Makefile:209: *** target pattern contains no '%'. Stop.
Line 209 is:$(BUILD)/$(ESPCOMP)/esp32/dport_access.o: CFLAGS += -Wno-array-bounds
My paths isE:\esp\esp-idf
I am on windows 10. I have downloaded the correct commit (with hash4ec2abbf23084ac060679e4136fa222a2d0ab0e8
) I use the precompiled toolchain from http://esp-idf.readthedocs.io/en/latest/get-started/windows-setup.html and mingw32.exe from that. What did I do wrong?