This isn't really working yet... I'm trying to understand what's happening, I'm not sure esp-idf 4.1 fixed this in the end...

I'm finding it difficult to get to the bottom of this... Looks to me like the xtensa tools used by esp-idf 4.1 still define EINPROGRESS=119. THat makes it incompatible with MP's definition of 115. As far as I can tell (it's hard to figure out where the errno.h include really comes from) the source is tools/xtensa-esp32-elf/esp-2020r2-8.2.0/xtensa-esp32-elf/xtensa-esp32-elf/include/sys/errno.h. I'd appreciate if someone else could verify this.

Assuming I'm correct, should we go back to #5968?

I did some more sleuthing... I see linux defining EINPROGRESS as 115 and other stuff, such as LwIP as 119. I don't know where this discrepancy comes from, but as far as I can tell, it's there. MP's uerrno says it's 115. LwIP and xtensa-esp32's newlib say it's 119. One option is for uerrno to get the value from the C header file and end up with 119 on the esp32 and 115 elsewhere. The other option is to enforce the 115. In the latter case, one option is to do it for LwIP like I did in #5968 and another is to do a translation everywhere. My head is spinning, I don't know which is 'best' and don't really care anymore. All I know is that it needs to be fixed one way or the other...

I had a look myself and it seems that ./tools/xtensa-esp32-elf/esp-2020r2-8.2.0/xtensa-esp32-elf/xtensa-esp32-elf/sys-include/sys/errno.h is where the errno definitions are ultimately coming from. And that has EINPROGRESS as 119.

So, how about just changing MICROPY_USE_INTERNAL_ERRNO to be 0 (ie disabled) on esp32? I know this was discussed in some detail in #5752, but I'm now think it's much cleaner to just use the system provided errno than trying to convert everything to the values defined in py/mperrno.h. Those constants were originally designed to be used on bare-metal ports that did not otherwise define/use system constants. It only really makes sense to use them if the whole system uses them (otherwise conversion is needed between the system calls and MicroPython).

I propose to support esp-idf v4.1 and up only, ditch support for v3.x and v4.0. It has to happen at some point and I think it's quite some extra work to put all the #ifdef in , test them, and eventually remove them. Users that want esp-idf v3 can stick to MP v1.13: it works great.

+1 I'll work on that in #6473 as soon as I can.

It would be really helpful to (a) get a branch going with the cmake stuff so it's easier to make PRs against that

Please see branch esp32-idf41-cmake on this repo. It's improved a bit since #6473 but not yet done. Feel free to target that branch for this PR.

superseded by #6613