[TW#20807] CMake-Based Build System Preview instructions very poor (IDFGH-1199)

[versamodule]

I would like to first thank you guys to help make things better!
The original "Standard Setup of Toolchain for Windows" instructions were clear on what to do for every step.
This new CMake-Based Build System Preview instructions are far from easy to understand each step.
Things like:
"Next Steps
To carry on with development environment setup, proceed to section Get ESP-IDF.
"
If I click on that link it takes me to needing to install mingw32, if i just click next a little lower at the bottom of the page I am shown "Setup for cmake on Windows from Scratch" What? I was just told eairlier to download "https://dl.espressif.com/dl/esp-idf-tools-setup-1.0.exe" which installs this automatically. This section is very confusing. Please, make it a step by step process and not page links jumping around here and there.

[projectgus]

Hi @versamodule,

Thanks for flagging this. We'll take a look at the docs and endeavour make the experience as streamlined as we can.

If i just click next a little lower at the bottom of the page I am shown "Setup for cmake on Windows from Scratch" What?

Will add this explanation which is missing from the docs (sincerely sorry for just dropping the context-free link in there), but for now: the "Setup for cmake on Windows from Scratch" is an alternative to using the ESP-IDF Tools installer. It's analogous to the two methods for Windows we have in the GNU Make build system documentation (either you can grab a zip file with MSYS+toolchain+everything, or there are "from scratch" instructions where you install everything bit by bit yourself.) Will make this clearer for cmake.

To carry on with development environment setup, proceed to section Get ESP-IDF.
"
If I click on that link it takes me to needing to install mingw32

I think I'm missing something here, because I can't see the mingw32 link.

Starting here:
https://docs.espressif.com/projects/esp-idf/en/feature-cmake/get-started/windows-setup-cmake.html

Scrolling to the bottom (I see there's definitely some cruft/cleanup needed here)
https://docs.espressif.com/projects/esp-idf/en/feature-cmake/get-started/windows-setup-cmake.html#next-steps

Then click the "Get ESP-IDF" link, I end up here:
https://docs.espressif.com/projects/esp-idf/en/feature-cmake/get-started/index-cmake.html#get-started-get-esp-idf-cmake

...which has the rest of the (non-platform-specific) steps for CMake on this page, but I don't see mingw32 mentioned. I'm guessing there's a stray link back to the other build system steps here, I just can't see it (or maybe it's because there are multiple headings with the same name in the two different sets of steps?)

Thanks for your help with this. Clearly the docs need improvement, and will put some time in today figuring out what we can do.

(Another thing with Windows that I'm unsure about is use of Git on Windows, and what tools are most popular. The current "Get ESP-IDF" cmake instructions will work with the "Git Bash" terminal which comes with the Git For Windows installer, but maybe it would help more people if we recommended something like Tortoise Git - and provided some Windows UI-oriented instructions? Any tips welcome.)

[ndotb]

gus, I just wanted to remind you (and your crew) of how awesome you are.

I saw the gripe about docs on the forum and while I had no trouble with it since I'm kinda battle-hardened from "enterprise" (heh) projects with word-of-mouth "knowledge of the ancients," I did jot down a few pointers.

1. On get-started/index-cmake.html#Configure it would be nice to have a reminder to windows users to ensure esp-idf\tools is added to the path (from my own goof)
2. It would also be nice to have a reminder to visual studio users to remind them to associate .py files with \python27 instead of python36 or whatever it installs. I'm thinking about doing a pull request for an idf.bat file that shortcuts this issue by calling c:\python27\python.exe directly.
3. Push anyone clueless about git on Windows to Github Desktop. It's pretty, it's simple, and most importantly, you don't have to maintain it!

I'd do a pull request for the doc updates mentioned, but I don't know what your traffic pattern looks like on the feature being as you guys are trying to wrap this into a release.

Get it wrapped up and I'll gift you guys your very own Visual Studio project template.

[projectgus]

Thanks for the kind words & the tips @ndotb !

Thanks also for the offer of a PR. At this point we're actually reviewing a full rewrite of the CMake preview docs (to swap over the "default" steps to use CMake), so don't worry about this too much. That should land in a day or so. I'll roll your tips into it.

Will add a Github Desktop link now, and look at making a graphical step-by-step for this in a future update.

[projectgus]

It would also be nice to have a reminder to visual studio users to remind them to associate .py files with \python27 instead of python36 or whatever it installs. I'm thinking about doing a pull request for an idf.bat file that shortcuts this issue by calling c:\python27\python.exe directly.

Is this the Python Tools plugin for Visual Studio? Will add a note.

We have a long overdue TODO item to make IDF work with Python 2 & 3. There's not a lot left to do there, so this maybe an incentive to finally push that over the line.

[projectgus]

Hi @versamodule @ndotb,

The docs have been updated so they use the exact same structure as the old ones. The new docs can be found here: https://docs.espressif.com/projects/esp-idf/en/feature-cmake/

Please let me know if you still see any errors or confusing sections.

Angus

[versamodule]

Thank you for the update!
I got as far as the "Configure" section without a problem.
I got an error running "idf.py menuconfig"
There is a note section that says "If you get an error about idf.py not being found, check the tools directory is part of your Path as described above in Setup Environment Variables."
when I look in the tools folder there is no idf.py file.

P.S. I see that the Eclipse section is not ready yet. Please also consider using Visual Studio Code as another option. I did a video of doing that here. https://www.youtube.com/watch?v=VPgEc8FUiqI&feature=youtu.be

[projectgus]

when I look in the tools folder there is no idf.py file.

Ah, thanks for pointing that out. The docs don't say to check out the feature/cmake branch with the preview version, so you'll end up with the master branch without cmake support and idf.py. Will add this instruction. From the command line, you can fix this by changing into the IDF directory and running git checkout feature/cmake to switch branches (or use your favourite GUI Git client).

P.S. I see that the Eclipse section is not ready yet. Please also consider using Visual Studio Code

It's not ready yet, but you may be pleasantly surprised at some time in the future...

[versamodule]

There 2 more fixes that i see. One more to be made in "Configure" section.
It says this:

For Windows Command Prompt users:
cd %userprofile%\esp
idf.py menuconfig

The problem is that your not changing into the hello_world folder first.
It should say:
For Windows Command Prompt users:
cd %userprofile%\esp\hello_world
idf.py menuconfig

The Second is I got this error when trying to flash:
C:\Users\Jim\esp\Projects\hello_world>idf.py -p COM5 erase_flash
Running esptool.py in directory C:\Users\Jim\esp\Projects\hello_world\build
Executing "C:\Users\Jim.platformio\python27\python.exe C:\Users\Jim\esp\esp-idf\components/esptool_py/esptool/esptool.py -p COM5 -b 460800 erase_flash"...
Traceback (most recent call last):
File "C:\Users\Jim\esp\esp-idf\components/esptool_py/esptool/esptool.py", line 34, in
import serial
ImportError: No module named serial
esptool.py failed with exit code 1

P.S. what is the reasoning for doing things this new way? Mingw32 was super simplistic. I am having a rough time converting projects from that to this new method. With Mingw32 I could just create new files in my main folder and it took care of things. This new way is not recognizing any of the new files.
Also, I don't see a way to just build it without flashing to the board.

CMakeFiles/hello-world.elf.dir/main/main.c.obj:(.literal.app_main+0x4c): undefined reference to taskCircleLED' CMakeFiles/hello-world.elf.dir/main/main.c.obj:(.literal.app_main+0x60): undefined reference to taskLCD'
CMakeFiles/hello-world.elf.dir/main/main.c.obj:(.literal.app_main+0x6c): undefined reference to spi_initme' CMakeFiles/hello-world.elf.dir/main/main.c.obj:(.literal.app_main+0x70): undefined reference to initI2C'
CMakeFiles/hello-world.elf.dir/main/main.c.obj: In function app_main': C:\Users\Jim\esp\Projects\Wrover_SPI_LCD_Test\build/../main/main.c:215: undefined reference to spi_initme'
C:\Users\Jim\esp\Projects\Wrover_SPI_LCD_Test\build/../main/main.c:216: undefined reference to `initI2C'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
ninja failed with exit code 1

[projectgus]

Hi @versamodule ,

Thanks for persisting with this, I appreciate the feedback.

cd %userprofile%\esp\hello_world

oops, will fix.

ImportError: No module named serial

I think I know what happened here. If the ESP-IDF Tools installer installs Python 2.7 then it will also install "pyserial" into Python. If Python 2.x is already installed then nothing happens.

Running "pip install pyserial" should fix this for now.

I'll see if we can extend the installer so it will offer to install pyserial into an existing Python install.

P.S. what is the reasoning for doing things this new way? Mingw32 was super simplistic

The rationale is set out in the announcemnt post: https://esp32.com/viewtopic.php?f=13&t=5559&p=24109 . Happy to elaborate on any point. I know things are still a bit rough at the moment, but we wanted to do the Preview Release partially to get this early feedback and also to let people get started experimenting with IDE integration.

With Mingw32 I could just create new files in my main folder and it took care of things. This new way is not recognizing any of the new files.

There's a list of changes between the "old" and "new" build system here, and also description of an automatic conversion tool for converting projects:
https://docs.espressif.com/projects/esp-idf/en/feature-cmake/api-guides/build-system.html#migrating-from-esp-idf-gnu-make-system

One thing that list doesn't mention explicitly (it's mentioned elsewhere in this document, but I'll put it into this section as well) is that "main" is no longer a component. This is because of some CMake assumptions about building executables.

Instead, the MAIN_SRCS variable in the project CMakeLists.txt file should be a list all of the source files which are part of the executable (ie the files in "main").

If you create "components" as part of your project (ie PROJDIR/components/name) then tyou can still have CMake detect all of the files in the component's COMPONENT_DIRS automatically, same as the old system.

(The trade-off here is that you have to add the files once, but not having to scan the filesystem for new files on every build makes the builds faster - and usually you build a lot more often than you add a new file.)

Also, I don't see a way to just build it without flashing to the board.

idf.py build. Will edit the Getting Started guide to mention this.

There's also a "cheat sheet" for GNU Make users here:
https://docs.espressif.com/projects/esp-idf/en/feature-cmake/api-guides/gnu-make-build-system.html#cheat-sheet

[versamodule]

@projectgus, Than you for all the very helpful information.
Just an FYI, this did not work.

Running "pip install pyserial" should fix this for now.

Had to do this: "python -m pip install serial"

[projectgus]

Had to do this: "python -m pip install serial"

Thanks for the heads-up. Do you happen to know what version of Python you have installed? (The one the ESP-IDF Tools installer bundles should install a pip.exe, but maybe there are other versions which don't do this by default.)

PS You probably installed pyserial, not serial. That's a whole 'nother thing...

[versamodule]

I have Python 2.7.13 Installed.

[projectgus]

Ah, I see now. If C:\Python27 is on the Path then it only adds Python.exe. C:\Python27\Scripts is the directory with pip.exe and friends. The Python installer adds both paths if you enable this option, but maybe a custom Path configuration won't have them both.

[projectgus]

I think the issues here should be improved in feature/cmake branch now. I'm going to close this, but if you find other shortcomings in the CMake getting started docs then please open new issues and we'll look into them.

Thanks again for helping us with this feedback.

[jcabad100]

Hello everyone, ...i have what it seems to be the very same problem, trying to make the hello_world application i get:
DELL@DESKTOP-MVQO1NB MINGW64 ~/esp/hello_world
$ idf.py menuconfig
Checking Python dependencies...
Python requirements from C:\Users\DELL\esp\esp-idf\requirements.txt are satisfie
d.
Running ninja in directory c:\users\dell\esp\hello_world\build
Executing "ninja menuconfig"...
[0/1] cmd.exe /C "cd /D C:\Users\DELL.../Users/DELL/esp/hello_world/sdkconfig"
/usr/bin/winpty: error: cannot start 'C:/Users/DELL/esp/esp-idf/Kconfig': %1 is
not a valid Win32 application. (error 0xc1)
FAILED: CMakeFiles/menuconfig
cmd.exe /C "cd /D C:\Users\DELL\esp\hello_world\build && D:\Phyton\Python27\pyth
on.exe C:/Users/DELL/esp/esp-idf/tools/kconfig_new/confgen.py --kconfig C:/Users
/DELL/esp/esp-idf/Kconfig --config C:/Users/DELL/esp/hello_world/sdkconfig --env
"COMPONENT_KCONFIGS=C:/Users/DELL/esp/esp-idf/components/app_trace/Kconfig C:/U
sers/DELL/esp/esp-idf/components/bt/Kconfig C:/Users/DELL/esp/esp-idf/components
/driver/Kconfig C:/Users/DELL/esp/esp-idf/components/efuse/Kconfig C:/Users/DELL
/esp/esp-idf/components/esp32/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_a
dc_cal/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_event/Kconfig C:/Users/D
ELL/esp/esp-idf/components/esp_http_client/Kconfig C:/Users/DELL/esp/esp-idf/com
ponents/esp_http_server/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_https_o
ta/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_wifi/Kconfig C:/Users/DELL/e
sp/esp-idf/components/espcoredump/Kconfig C:/Users/DELL/esp/esp-idf/components/e
thernet/Kconfig C:/Users/DELL/esp/esp-idf/components/fatfs/Kconfig C:/Users/DELL
/esp/esp-idf/components/freemodbus/Kconfig C:/Users/DELL/esp/esp-idf/components/
freertos/Kconfig C:/Users/DELL/esp/esp-idf/components/heap/Kconfig C:/Users/DELL
/esp/esp-idf/components/libsodium/Kconfig C:/Users/DELL/esp/esp-idf/components/l
og/Kconfig C:/Users/DELL/esp/esp-idf/components/lwip/Kconfig C:/Users/DELL/esp/e
sp-idf/components/mbedtls/Kconfig C:/Users/DELL/esp/esp-idf/components/mdns/Kcon
fig C:/Users/DELL/esp/esp-idf/components/mqtt/Kconfig C:/Users/DELL/esp/esp-idf/
components/nvs_flash/Kconfig C:/Users/DELL/esp/esp-idf/components/openssl/Kconfi
g C:/Users/DELL/esp/esp-idf/components/pthread/Kconfig C:/Users/DELL/esp/esp-idf
/components/spi_flash/Kconfig C:/Users/DELL/esp/esp-idf/components/spiffs/Kconfi
g C:/Users/DELL/esp/esp-idf/components/tcpip_adapter/Kconfig C:/Users/DELL/esp/e
sp-idf/components/unity/Kconfig C:/Users/DELL/esp/esp-idf/components/vfs/Kconfig
C:/Users/DELL/esp/esp-idf/components/wear_levelling/Kconfig" --env "COMPONENT_K
CONFIGS_PROJBUILD=C:/Users/DELL/esp/esp-idf/components/app_update/Kconfig.projbu
ild C:/Users/DELL/esp/esp-idf/components/bootloader/Kconfig.projbuild C:/Users/D
ELL/esp/esp-idf/components/esptool_py/Kconfig.projbuild C:/Users/DELL/esp/esp-id
f/components/partition_table/Kconfig.projbuild" --env IDF_CMAKE=y --env IDF_TARG
ET=esp32 --env IDF_TARGET=esp32 --output config C:/Users/DELL/esp/hello_world/sd
kconfig && "C:\Program Files\CMake\bin\cmake.exe" -E env "COMPONENT_KCONFIGS=C:/
Users/DELL/esp/esp-idf/components/app_trace/Kconfig C:/Users/DELL/esp/esp-idf/co
mponents/bt/Kconfig C:/Users/DELL/esp/esp-idf/components/driver/Kconfig C:/Users
/DELL/esp/esp-idf/components/efuse/Kconfig C:/Users/DELL/esp/esp-idf/components/
esp32/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_adc_cal/Kconfig C:/Users/
DELL/esp/esp-idf/components/esp_event/Kconfig C:/Users/DELL/esp/esp-idf/componen
ts/esp_http_client/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_http_server/
Kconfig C:/Users/DELL/esp/esp-idf/components/esp_https_ota/Kconfig C:/Users/DELL
/esp/esp-idf/components/esp_wifi/Kconfig C:/Users/DELL/esp/esp-idf/components/es
pcoredump/Kconfig C:/Users/DELL/esp/esp-idf/components/ethernet/Kconfig C:/Users
/DELL/esp/esp-idf/components/fatfs/Kconfig C:/Users/DELL/esp/esp-idf/components/
freemodbus/Kconfig C:/Users/DELL/esp/esp-idf/components/freertos/Kconfig C:/User
s/DELL/esp/esp-idf/components/heap/Kconfig C:/Users/DELL/esp/esp-idf/components/
libsodium/Kconfig C:/Users/DELL/esp/esp-idf/components/log/Kconfig C:/Users/DELL
/esp/esp-idf/components/lwip/Kconfig C:/Users/DELL/esp/esp-idf/components/mbedtl
s/Kconfig C:/Users/DELL/esp/esp-idf/components/mdns/Kconfig C:/Users/DELL/esp/es
p-idf/components/mqtt/Kconfig C:/Users/DELL/esp/esp-idf/components/nvs_flash/Kco
nfig C:/Users/DELL/esp/esp-idf/components/openssl/Kconfig C:/Users/DELL/esp/esp-
idf/components/pthread/Kconfig C:/Users/DELL/esp/esp-idf/components/spi_flash/Kc
onfig C:/Users/DELL/esp/esp-idf/components/spiffs/Kconfig C:/Users/DELL/esp/esp-
idf/components/tcpip_adapter/Kconfig C:/Users/DELL/esp/esp-idf/components/unity/
Kconfig C:/Users/DELL/esp/esp-idf/components/vfs/Kconfig C:/Users/DELL/esp/esp-i
df/components/wear_levelling/Kconfig" "COMPONENT_KCONFIGS_PROJBUILD=C:/Users/DEL
L/esp/esp-idf/components/app_update/Kconfig.projbuild C:/Users/DELL/esp/esp-idf/
components/bootloader/Kconfig.projbuild C:/Users/DELL/esp/esp-idf/components/esp
tool_py/Kconfig.projbuild C:/Users/DELL/esp/esp-idf/components/partition_table/K
config.projbuild" IDF_CMAKE=y KCONFIG_CONFIG=C:/Users/DELL/esp/hello_world/sdkco
nfig D:/Programs/Git/usr/bin/winpty.exe C:/Users/DELL/esp/esp-idf/Kconfig && D:
Phyton\Python27\python.exe C:/Users/DELL/esp/esp-idf/tools/kconfig_new/confgen.p
y --kconfig C:/Users/DELL/esp/esp-idf/Kconfig --config C:/Users/DELL/esp/hello_w
orld/sdkconfig --env "COMPONENT_KCONFIGS=C:/Users/DELL/esp/esp-idf/components/ap
p_trace/Kconfig C:/Users/DELL/esp/esp-idf/components/bt/Kconfig C:/Users/DELL/es
p/esp-idf/components/driver/Kconfig C:/Users/DELL/esp/esp-idf/components/efuse/K
config C:/Users/DELL/esp/esp-idf/components/esp32/Kconfig C:/Users/DELL/esp/esp-
idf/components/esp_adc_cal/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_even
t/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_http_client/Kconfig C:/Users/
DELL/esp/esp-idf/components/esp_http_server/Kconfig C:/Users/DELL/esp/esp-idf/co
mponents/esp_https_ota/Kconfig C:/Users/DELL/esp/esp-idf/components/esp_wifi/Kco
nfig C:/Users/DELL/esp/esp-idf/components/espcoredump/Kconfig C:/Users/DELL/esp/
esp-idf/components/ethernet/Kconfig C:/Users/DELL/esp/esp-idf/components/fatfs/K
config C:/Users/DELL/esp/esp-idf/components/freemodbus/Kconfig C:/Users/DELL/esp
/esp-idf/components/freertos/Kconfig C:/Users/DELL/esp/esp-idf/components/heap/K
config C:/Users/DELL/esp/esp-idf/components/libsodium/Kconfig C:/Users/DELL/esp/
esp-idf/components/log/Kconfig C:/Users/DELL/esp/esp-idf/components/lwip/Kconfig
C:/Users/DELL/esp/esp-idf/components/mbedtls/Kconfig C:/Users/DELL/esp/esp-idf/
components/mdns/Kconfig C:/Users/DELL/esp/esp-idf/components/mqtt/Kconfig C:/Use
rs/DELL/esp/esp-idf/components/nvs_flash/Kconfig C:/Users/DELL/esp/esp-idf/compo
nents/openssl/Kconfig C:/Users/DELL/esp/esp-idf/components/pthread/Kconfig C:/Us
ers/DELL/esp/esp-idf/components/spi_flash/Kconfig C:/Users/DELL/esp/esp-idf/comp
onents/spiffs/Kconfig C:/Users/DELL/esp/esp-idf/components/tcpip_adapter/Kconfig
C:/Users/DELL/esp/esp-idf/components/unity/Kconfig C:/Users/DELL/esp/esp-idf/co
mponents/vfs/Kconfig C:/Users/DELL/esp/esp-idf/components/wear_levelling/Kconfig
" --env "COMPONENT_KCONFIGS_PROJBUILD=C:/Users/DELL/esp/esp-idf/components/app_u
pdate/Kconfig.projbuild C:/Users/DELL/esp/esp-idf/components/bootloader/Kconfig.
projbuild C:/Users/DELL/esp/esp-idf/components/esptool_py/Kconfig.projbuild C:/U
sers/DELL/esp/esp-idf/components/partition_table/Kconfig.projbuild" --env IDF_CM
AKE=y --env IDF_TARGET=esp32 --env IDF_TARGET=esp32 --output config C:/Users/DEL
L/esp/hello_world/sdkconfig"
ninja: build stopped: subcommand failed.
ninja failed with exit code 1

..... therefore the error is "error: cannot start 'C:/Users/DELL/esp/esp-idf/Kconfig': %1 is
not a valid Win32 application. (error 0xc1) " ...i cannot understand it as the Kconfig file is a text file and not a binary nor an executable.....(My environment is Window 10 64bits, MINGW64, Python 2.7.14 (reinstalled after the tools as i had another newers Python version 3+ that i uninstalled first)...Please help!

[jcabad100]

I found a workaround, first just build it "$ idf.py build" (which was successful despite previous above error) and then flash it "$ idf.py -p COM8 flash" ...still i would be nice to know why the "idf.py menuconfig" fails...thank you!

[projectgus]

HI @jcabad100 ,

Thanks for reporting this. I don't think what you're seeing is related to the older issue above.

Could you please open a new issue and provide all these details plus the other details which are asked for in the issue template (most importantly, the IDF version you are using). Thanks.

[jcabad100]

Ok, i will try, thx ( i do have much more issues with the other examples that would not build...i will open at least two new issues...

[freedaun]

I just ran the installer, this is about https://docs.espressif.com/projects/esp-idf/en/latest/get-started/index.html#id9:

• cd %userprofile%\esp\hello_world doesn't work, there is no folder esp
• Surprise: the idf was installed on my desktop (I didn't see the box below the version selection), strange place to install in. Why not in %userprofile%\esp-idf, or %userprofile%\esp\idf?
• note, as a Windows user I don't like to access %userprofile%, neither do I like My documents equivalents.
• best place for code is still some root folder, so having everything installed to \esp would be fine

[igrr]

cd %userprofile%\esp\hello_world doesn't work, there is no folder esp

Thanks, will correct the guide to explain that the path needs to be adjusted to the one used in the installer.

Regarding the default location where IDF is cloned, the normal place where "data" should be placed on Windows is the Documents folder. I am not sure why the default is currently "Desktop", we will correct that. Regarding installing into the root directory, I think this is not a recommended practice on Windows. However the installer does allow you to choose the path if you prefer to use the root path.
Do you think it will be easier to notice this prompt if we put it on a separate installer page?

[freedaun]

Regarding installing into the root directory, I think this is not a recommended practice on Windows.

Languages/environments like Lazarus, Go and Flutter do use that system. Short pathnames are more important than one might think, if only to prevent lines in the output from breaking up.

However the installer does allow you to choose the path if you prefer to use the root path.

Yes, I uninstalled (.espressif itself wasn't deleted) and then reinstalled. Apparently all is fine.

Do you think it will be easier to notice this prompt if we put it on a separate installer page?

I do think so, it is an important decision for many. But I'm sure if the default location was fine, that would make less of a difference.

[igrr]

Yes, I uninstalled (.espressif itself wasn't deleted) and then reinstalled. Apparently all is fine.

Sorry, a bit confused here: was your issue related to the location where IDF is cloned (Desktop) or where the tools are installed (%userprofile%\.espressif)? The latter is already set on a separate installer page. And the uninstall process doesn't remove IDF copy, only the tools in .espressif.

[freedaun]

Sorry, a bit confused here: was your issue related to the location where IDF is cloned (Desktop) or where the tools are installed (%userprofile%\.espressif)? The latter is already set on a separate installer page. And the uninstall process doesn't remove IDF copy, only the tools in .espressif.

No confusion here. This comment was about the uninstall, and insignificant.

[freedaun]

Regarding installing into the root directory, I think this is not a recommended practice on Windows.

Languages/environments like Lazarus, Go and Flutter do use that system. Short pathnames are more important than one might think, if only to prevent lines in the output from breaking up.

I have come to think about this a little more. The issue is more important than it seems, and shortness of paths is not the main issue.

When the default install uses C:\esp, all communication of both users and the docs (in their examples) can assume absolute paths, simplifying them greatly, and scripts and instructions work without customization.

In addition it would be possible to make a portable install, and pass the project to someone, without needing an installation or instructions.

These things make a BIG difference in ergonomics for the user and for you folks. Heck, even Python (supposedly battle tested) doesn't correctly handle its installs. I have seen cases where I have to uninstall then reinstall to get the desired behaviour. Reliability (of install and communications) is highly favored by simplicity.

But doing it this way of course means only one install per machine. Which isn't standard practice, except for development, as exemplified by the examples I gave (and have installed).

Also, anything that depends on instructions is bad, as humans are bad at following instructions. Inevitably they introduce small differences that later cause breakage, without anyone being able to pinpoint why. It is therefore important to minimize such needless variations. The insertion of a username in a path is such a thing. Is the benefit worth the costs? I'm now firmly in the "No" camp. I think it is mistake.

[an-dr]

A few words about the install place.

As I know, user-installed apps are tending to install to %appdata%/Local (which is equal to %userprofile/AppData/Local%). For example, VS Code for user-only offers this folder:

System-wide traditionally are installing to:
C:\Program Files\VENDOR\APP_NAME

For back compatibility commonly Microsoft uses Juncuion links (e.g. AppData was Application Data). We could create one at C:\esp optionally

[freedaun]

The common install locations are perfect for when the user has no interaction with them, they keep the install out of the way and, additionally, grouped per user. For development "out of the way" is largely a negative.

I now ran my first build and it serves as an example of the impact of paths. Note I didn't find any project-migration instructions (from MSYS32 to CMake), so it failed. I got messages like this (which still wrap even in a fullscreen 237 column wide terminal):

c:/users/some stupid user/.espressif/tools/xtensa-esp32-elf/esp32-2019r1-8.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: c:\esp\projects\my_project\build/../main/app_main.c:1234: undefined reference to 'something'

These messages are sometimes the only way to diagnose a problem. But I would be much happier with:

xtensa-esp32-elf/bin/ld.exe: c:\esp\projects\my-project\main/app_main.c:1234: undefined reference to 'something'

I understand these messages are not really under your control, but they illustrate paths do make a big difference.

cmd.exe complicates matters further, relative to MSYS32, as there are no colors. Now back to my project :/ Thanks for making this work and generally doing a very good job.

[projectgus]

@freedaun Thanks for explaining this concern. I agree this is a legitimate difficulty (path noise in error messages) and we'll try to find a way to improve it if possible.

One request, could you please open a new issue describing this issue (feel free to link back to this discussion)? This thread already has a number of other discussions about different aspects of CMake in it, and it makes it hard for us to keep track.

cmd.exe complicates matters further, relative to MSYS32, as there are no colors

For the record, you don't have to use cmd.exe - it should be possible to build under an MSYS2 terminal or Git Bash (which is also MSYS2), PowerShell, etc.

We changed the instructions to use Windows Shell because this is more familiar for Windows users, and we don't require the Unix emulation environment any more. But it should still be available for those who want it.

[projectgus]

To everyone seeing this in the future: Please open new issues for new problems in CMake (if no other issue describes the problem you see), rather than replying here.

(I've locked this not because we don't care about CMake issues but because we do care about them, and tracking a number of discussions in a long thread makes it hard for us to address them all.)