python cannot be found on March 30 release of MSYS

[amatani]

'make' fails with the 20170330 release of "esp32_win32_environment_and_toolchain-20170330.zip"
$ make /bin/sh: python: command not found make[1]: *** [/c/projects/esp32/esp-idf/components/esptool_py/Makefile.projbuild:49: /c/projects/esp32/myproj/esp-idf-template/build/bootloader/bootloader.bin] Error 127 make: *** [/c/projects/esp32/esp-idf/components/bootloader/Makefile.projbuild:31: /c/projects/esp32/myproj/esp-idf-template/build/bootloader/bootloader.bin] Error 2
Checked for python.exe:
$ which python which: no python in (/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/opt/xtensa-esp32-elf/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
and path
$ echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/opt/xtensa-esp32-elf/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
Compared with "esp32_win32_environment_and_toolchain-20170111.zip" release and build completes.
Found the following differences:
$ which python /mingw32/bin/python
and
$ echo $PATH /mingw32/bin:/usr/local/bin:/usr/bin:/bin:/c/windows/system32:/c/windows:/c/windows/system32/wbem:/opt/xtensa-esp32-elf/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
In both cases, using esp-idf v2 release from github

[projectgus]

Hi @amatani ,

I'm not able to reproduce this. If I take a clean VM and unzip the esp32_win32_msys2_environment_and_toolchain-20170330.zip file (size 502251094 bytes, md5sum afe3f5ed11bfa6bcc4088547e1041d16) to C:\MSYS32 and then follow these steps:

• Use Windows "Run" (Window-R) "C:\msys32\mingw32.exe" to open a terminal
• Type which python at the prompt.

... and python.exe is correctly found (its Windows path is C:\msys32\mingw32\bin\python.exe).

Is it possible that the unzipping process was interrupted, so not all files were unzipped to the filesystem? Or are you running a different msys32 directory's prompt?

[amatani]

Hello Angus,
Thanks for looking into this.
On my Windows 10 PC, I did a fresh download of zip archive from:
https://dl.espressif.com/dl/esp32_win32_msys2_environment_and_toolchain-20170330.zip
The checksum matches:
md5sum = afe3f5ed11bfa6bcc4088547e1041d16

I run C:/msys32/msys2_shell.cmd

Seems to me that "/mingw32/bin" is not in the path
The ~20170111.zip version does have this in the path.

Also, I see this:

[amatani]

Sorry I closed by mistake, so reopened

[amatani]

Could this be the problem due to differences in ~/msys32/etc/profile.d/esp32_toolchain.sh ?

[amatani]

FYI: I added the path along with IDF_PATH and build completes

Also checked 'make flash' and it works fine.

[projectgus]

What you've done will work. The other difference is running MSYS vs MINGW32:

I run C:/msys32/msys2_shell.cmd

You need to run C:/msys32/mingw32.exe and then you'll get /bin/mingw32 on your path automatically.

You can tell the difference in the screenshots, my screenshot has purple MINGW32 and your screenshots have purple MSYS. Different shell types have different paths (there are annoying technical reasons for this, we need a MINGW32 "native" Python not an MSYS Python in order to use COM ports natively.)

The old instructions said to run the other command line msys2_shell.cmd, which worked because the profile.d added the mingw32 path (the same way you have added it). This is not technically the "correct MSYS way". This is why it's been changed in the newer instructions which say to run mingw32.exe.

[amatani]

OK, I see now.

I missed it as I had skipped to STEP 4 to configure IDF_PATH
I suggest that the document be updated for STEP 4 also.

Thanks. I have reverted to the new way and I like the fact that 'make monitor' works on my Windows 10 machine !!! (no more opening PuTTY, and remembering to close when firmware update is needed)

You may close this issue when appropriate (i.e. if you decide to update STEP 4 in doc or otherwise)

[projectgus]

Snap, sorry about that! Will fix ASAP.

[fake-name]

Out of curiosity, if things like the msys2_shell.cmd can cause issues like this, why is it even still present?

Wouldn't it be better to remove the other ways of executing the msys shell, to reduce confusion? Or are they executed somehow?

Out of curiosity, I moved mingw64.exe, msys2.exe, and msys2_shell.cmd out of the directory, and things seem to build OK.