search

micropython / micropython-esp32

Old port of MicroPython to the ESP32 -- new port is at https://github.com/micropython/micropython
MIT License
678 stars 218 forks source link

Makefile:209: *** target pattern contains no '%'. Stop. #142

Closed emilekm2142 closed 5 years ago

emilekm2142 commented 7 years ago

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 is E:\esp\esp-idf I am on windows 10. I have downloaded the correct commit (with hash 4ec2abbf23084ac060679e4136fa222a2d0ab0e8) 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?

dpgeorge commented 7 years ago

What did I do wrong?

I'm not sure. What path is this repository in, ie what is the value of $(BUILD)?

nickzoic commented 7 years ago

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/

pingswept commented 7 years ago

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.

nickzoic commented 7 years ago

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

pingswept commented 7 years ago

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.

nickzoic commented 7 years ago

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 ...)

nickzoic commented 7 years ago

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.

chrismas9 commented 7 years ago

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:

  1. Handle existing symlinks under Windows by parsing the link.
  2. Allow Windows users to create fake links or a list of modules.
  3. Support separate FROZEN_DIR for port, board and user projects.

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.

dpgeorge commented 5 years ago

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