Error: Too long output directory

[achieve-dream1221]

create a project by cargo generate esp-rs/esp-idf-template cargo and then, run cargo build

error: failed to run custom build command for esp-idf-sys v0.33.3

Caused by: process didn't exit successfully: E:\rust\esp32-std-project\target\debug\build\esp-idf-sys-7beb8c60ac8a9a8b\build-script-build (exit code: 1) --- stderr Error: Too long output directory: \\?\E:\rust\esp32-std-project\target\xtensa-esp32-espidf\debug\build\esp-idf-sys-168dae4d88221cf9\out. Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work! warning: build failed, waiting for other jobs to finish...

### Tasks

[0x1f57]

this works for me

in project

you may also need to "cargo clean" and delete the ".embuild" folder

[Vollbrecht]

On windows please try to put your projects in root project like C:\your-project to make the path as short as possible or use WSL as it has not such a problem. This is a windows specific problem we cant influence.

[emeric-martineau]

In my case, ESP_IDF_PATH_ISSUES works but I have another error after:

Caused by:
  process didn't exit successfully: `D:\rust\esp32-std-blink-led\target\debug\build\esp-idf-sys-7beb8c60ac8a9a8b\build-script-build` (exit code: 1)
  --- stdout
  cargo:warning=(esp-idf-sys) Too long output directory: `\\?\D:\rust\esp32-std-blink-led\target\xtensa-esp32-espidf\debug\build\esp-idf-sys-168dae4d88221cf9\out`. Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows `subst` do NOT work!
  cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
  cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
  cargo:rerun-if-env-changed=MCU
  cargo:rerun-if-env-changed=ESP_IDF_SYS_ROOT_CRATE
  cargo:rerun-if-env-changed=ESP_IDF_VERSION
  cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
  cargo:rerun-if-env-changed=ESP_IDF_CMAKE_GENERATOR
  cargo:rerun-if-env-changed=IDF_PATH
  cargo:rerun-if-env-changed=EXTRA-COMPONENTS
  cargo:rerun-if-env-changed=ESP_IDF_COMPONENTS
  cargo:rerun-if-env-changed=ESP_IDF_COMPONENT_MANAGER
  Submodule path 'components/asio/asio': checked out 'f31694c9f1746ba189a4bcae2e34db15135ddb22'
  Submodule path 'components/bootloader/subproject/components/micro-ecc/micro-ecc': checked out 'd037ec89546fad14b5c4d5456c2e23a71e554966'
  Submodule path 'components/bt/controller/lib_esp32': checked out '7bb0d445db3414ce96d21c50ba9249125d41480f'
  Submodule path 'components/bt/controller/lib_esp32c3_family': checked out '0cfac1b21ebc995e8e9aa040ab1ab29deee4f580'
  Submodule path 'components/bt/host/nimble/nimble': checked out 'e2d7a766fb3927d008902611b3985e8595864c55'
  Submodule path 'components/cbor/tinycbor': checked out '7c349dbb6b8d76db39383b226d3ebdf59b8ab37d'
  Submodule path 'components/cmock/CMock': checked out 'eeecc49ce8af123cf8ad40efdb9673e37b56230f'
  Submodule path 'components/cmock/CMock/vendor/c_exception': checked out '71b47be7c950f1bf5f7e5303779fa99a16224bb6'
  Submodule path 'components/cmock/CMock/vendor/unity': checked out 'cf949f45ca6d172a177b00da21310607b97bc7a7'
  Submodule path 'components/coap/libcoap': checked out '3aa11612c143c9734d72022720f33e12506f7a2c'
  Submodule path 'components/coap/libcoap/ext/tinydtls': checked out '59055b8a935bc53bf69d002fc089ad4bd08851b2'
  Submodule path 'components/esp_phy/lib': checked out '32583f98f229ab9b3c48aa3a10f954fcdddfe4d1'
  Submodule path 'components/esp_wifi/lib': checked out 'a9f72f895dd74bb763f1ff9146203ff57846ab5d'
  Submodule path 'components/esptool_py/esptool': checked out '7b17ea072fbac0f92fc417ddbe34e28afbd8ced0'
  Submodule path 'components/expat/expat': checked out '454c6105bc2d0ea2521b8f8f7a5161c2abd8c386'
  Submodule path 'components/ieee802154/lib': checked out 'f7b5e8059a3bb6f321e79ac3bf2aa4d2a9b93326'
  Submodule path 'components/json/cJSON': checked out 'd348621ca93571343a56862df7de4ff3bc9b5667'
  Submodule path 'components/libsodium/libsodium': checked out '4f5e89fa84ce1d178a6765b8b46f2b6f91216677'
  Submodule path 'components/lwip/lwip': checked out '4f24c9baf9101634b7c690802f424b197b3bb685'
  Submodule path 'components/mbedtls/mbedtls': checked out '1d7033af30e20ccb2a0c0a114d3a08e372430f34'
  Submodule path 'components/mqtt/esp-mqtt': checked out 'bb9c8af9d552b608dd3aabf9617bde757a538ebe'
  Submodule path 'components/nghttp/nghttp2': checked out '8f7b008b158e12de0e58247afd170f127dbb6456'
  Submodule path 'components/nghttp/nghttp2/third-party/mruby': checked out '7c91efc1ffda769a5f1a872c646c82b00698f1b8'
  Submodule path 'components/nghttp/nghttp2/third-party/neverbleed': checked out 'b967ca054f48a36f82d8fcdd32e54ec5144f2751'
  Submodule path 'components/openthread/lib': checked out '9a8d34d8f698cad2c9468468b473e26a3dda51b9'
  Submodule path 'components/openthread/openthread': checked out 'c36c0e77a2465355bcf13bd7dc718d8c9aa6ff64'
  Submodule path 'components/protobuf-c/protobuf-c': checked out 'abc67a11c6db271bedbb9f58be85d6f4e2ea8389'
  Submodule path 'components/spiffs/spiffs': checked out '0dbb3f71c5f6fae3747a9d935372773762baf852'
  Submodule path 'components/tinyusb/tinyusb': checked out 'c4badd394eda18199c0196ed0be1e2d635f0a5f6'
  Submodule path 'components/unity/unity': checked out '7d2bf62b7e6afaf38153041a9d53c21aeeca9a25'
  Submodule path 'examples/build_system/cmake/import_lib/main/lib/tinyxml2': checked out '7e8e249990ec491ec15990cf95b6d871a66cf64a'
  Submodule path 'examples/peripherals/secure_element/atecc608_ecdsa/components/esp-cryptoauthlib': checked out '36d0642e66ff5b1c7a291873f24c498ca6ffedef'

To use WSL2, remember, that WSL2 don't have access to your USB device. You must install Rust both under Linux and Windows.

Under linux, install all ESP32 tools (see https://esp-rs.github.io/book/). Under Windows install only espflash and run:

# To upload binary
$ espflash.exe flash --port COM3 esp32-std-blink-led
# To upload and display log from you code
$ espflash.exe flash --port COM3 --monitor esp32-std-blink-led

Where esp32-std-blink-led is you ELF binary after compile found in your Rust project target/xtensa-esp32-espidf/debug/

It works for me.

[achieve-dream1221]

this works for me

in project

you may also need to "cargo clean" and delete the ".embuild" folder

thank you so much, it worked!

[Julien-cpsn]

this works for me

in project

you may also need to "cargo clean" and delete the ".embuild" folder

Just for precision : this line goes into the .cargo/config.toml file

[xobs]

I think this workaround should be enabled by default if it isn't fatal. Note that the recommended workaround doesn't work, so the documentation should be updated to reflect this approach instead: https://esp-rs.github.io/book/misc/troubleshooting.html#long-path-names

[ivmarkov]

I think this workaround should be enabled by default if it isn't fatal. Note that the recommended workaround doesn't work, so the documentation should be updated to reflect this approach instead: https://esp-rs.github.io/book/misc/troubleshooting.html#long-path-names

What workaround should be enabled by default if it isn't fatal? If you mean ESP_IDF_PATH_ISSUES=warn - this is BAD, because - depending on what bits and pieces you use from ESP IDF - your build might fail in weird ways (partial git clones, strange build errors). This workaround is a bit "use at your own risk".

And I'm not enabling it by default no matter what, as we were flooded by "I have a weird build failure on Windows" errors before.

As for the trick described in the ESP book, I don't know why it is there, given that - last time I checked - it does NOT work for esp-idf-sys. Again, the error message is: {quote} Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work! {quote}

(Emphasis mine.)

Otherwise, thanks to you and the rest of the folks trying to help! Unfortunately I'm not very optimistic we can improve the "too long Windows path" issue handling beyond what we have and what we suggest.

[ivmarkov]

UPDATE: For the "subst" trick - I've posted a question in the Matrix chat as I'm not sure who was ever successfully using that. But other than that, not sure what else to do here. Closing :)

[Tastaturtaste]

UPDATE: For the "subst" trick - I've posted a question in the Matrix chat as I'm not sure who was ever successfully using that. But other than that, not sure what else to do here. Closing :)

I just successfully used that trick. What error did you @ivmarkov get when trying it out? Did you have windows long path support set up correctly?

[ivmarkov]

@Tastaturtaste

UPDATE: For the "subst" trick - I've posted a question in the Matrix chat as I'm not sure who was ever successfully using that. But other than that, not sure what else to do here. Closing :)

I just successfully used that trick. What error did you @ivmarkov get when trying it out? Did you have windows long path support set up correctly?

• This trick (SUBST) does not work, plain and simple. I have in the meantime tested it.
• The link you've pasted w.r.t. regedits mentions that there are TWO issues that need to be fulfilled for that to work. The regedit is just one of them.

[archifo]

Does it mean that it is definitively impossible to use Rust for espressif on windows ? Sorry but I'm quite angry. Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea? I've never seen this kind of problem with other chipsets supporting Rust...

[ivmarkov]

Does it mean that it is definitively impossible to use Rust for espressif on windows ?

It is possible. In the original bug report, as well as throughout the thread that follows, as well as in the error message that the build spits out, the solution is given:

"Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!"

Sorry but I'm quite angry.

Espressif is currently investing (as in hired, full time developers) in the baremetal crates, not the ones which are based on top of ESP-IDF. Either because they consider the baremetal solutions more important, or because they think the ESP-IDF crates are in the meantime relatively mature, or both. Speculating here a bit, but that's the status quo.

Therefore, the effort put into esp-idf-sys/hal/svc is based on mine (and others) free time. As in good will and so on.

Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea?

Not sure for that suggestion. Might or might not work. If we go this route, we have to put not just build artefacts, but also the ESP IDF git repo itself in something like /tmp/<short-tmp-dir>.

Another solution would be to make sure that ALL tools involved in building the esp-idf-sys crate itself as well as the ESP-IDF itself understand long paths, and if not - fix them. Perhaps possible, but definitely not easy.

You also need to realize, that the "please use a short project path" restriction is coming from ESP IDF itself. It is just that the cargo build system is making it worse (as in the project path needs to be even shorter).

I've never seen this kind of problem with other chipsets supporting Rust...

Espressif's ESP IDF is unique in its class in that it provides you a Rust STD environment. On an MCU. Therefore, I think this "short project path" constraint on pure Windows (it does not exist with WSL2's native file system) is a small price to pay for that. Surely annoying, but tolerable. But then - IMO. Perhaps if you or other folks find this really inconvenient, you can work towards a solution?

[N3xed]

Does it mean that it is definitively impossible to use Rust for espressif on windows ? Sorry but I'm quite angry. Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea? I've never seen this kind of problem with other chipsets supporting Rust...

Well, you can always give your hands on trying to create a workaround for this. I originally wrote this compilation infrastructure on Windows, where we ran into command-line length limitations (see https://github.com/esp-rs/esp-idf-sys/pull/7#issuecomment-909164445 and https://github.com/espressif/esp-idf/issues/7864), which was fixed by using response files and preventing the linker to expand the response files while running the jobs.

Then, someone ran into Windows file path limitations (see https://github.com/esp-rs/esp-idf-sys/issues/23). Which seems to be caused by gcc no supporting long paths on Windows (see my comment https://github.com/esp-rs/esp-idf-sys/issues/23#issuecomment-956238333). There may be other tools that we're using that also don't support this (e.g. I seem to remember there were some issues with git and too long paths as well).

The original workarounds I posted are:

Possible workarounds:

• Use subst to assign a virtual drive letter to a path (should work as pointed out here).

• Create a directory junction (with mklink /j) to shorten the path (not tested).

• Moving the project to a directory with a shorter path.

Where point one seems not to work. But maybe point 2 could? The issue is also with the system headers (e.g. for newlib) which reside in the .embuild directory. So I think only moving your project to a shorter path may not actually help if your .embuild folder where the toolchain is stored is also at a long path. But almost certainly the root cause is still GCC not supporting long paths.

I've been pretty inactive, and am also not building stuff with esp-idf-sys, so I've not looked into workarounds further. But again if anyone wants improvements in this regard, you'd (or anyone) have to it yourself.

[Tastaturtaste]

Regarding the gcc side of the problem there is this tracked bug. According to one of the comments the fix was simply to add a manifest to enable long path support on windows. It seems nobody has pursued this further.

[RingCanary]

Does it mean that it is definitively impossible to use Rust for espressif on windows ?

It is possible. In the original bug report, as well as throughout the thread that follows, as well as in the error message that the build spits out, the solution is given:

"Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!"

Sorry but I'm quite angry.

Espressif is currently investing (as in hired, full time developers) in the baremetal crates, not the ones which are based on top of ESP-IDF. Either because they consider the baremetal solutions more important, or because they think the ESP-IDF crates are in the meantime relatively mature, or both. Speculating here a bit, but that's the status quo.

Therefore, the effort put into esp-idf-sys/hal/svc is based on mine (and others) free time. As in good will and so on.

Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea?

Not sure for that suggestion. Might or might not work. If we go this route, we have to put not just build artefacts, but also the ESP IDF git repo itself in something like /tmp/<short-tmp-dir>.

Another solution would be to make sure that ALL tools involved in building the esp-idf-sys crate itself as well as the ESP-IDF itself understand long paths, and if not - fix them. Perhaps possible, but definitely not easy.

You also need to realize, that the "please use a short project path" restriction is coming from ESP IDF itself. It is just that the cargo build system is making it worse (as in the project path needs to be even shorter).

I've never seen this kind of problem with other chipsets supporting Rust...

Espressif's ESP IDF is unique in its class in that it provides you a Rust STD environment. On an MCU. Therefore, I think this "short project path" constraint on pure Windows (it does not exist with WSL2's native file system) is a small price to pay for that. Surely annoying, but tolerable. But then - IMO. Perhaps if you or other folks find this really inconvenient, you can work towards a solution?

It's better to use WSL2 as recommended and please refer this to bind the usb ports to the hosted linux distro -- things works like a charm :)

[ivmarkov]

Does it mean that it is definitively impossible to use Rust for espressif on windows ?

It is possible. In the original bug report, as well as throughout the thread that follows, as well as in the error message that the build spits out, the solution is given: "Shorten your project path down to no more than 10 characters (or use WSL2 and its native Linux filesystem). Note that tricks like Windows subst do NOT work!"

Sorry but I'm quite angry.

Espressif is currently investing (as in hired, full time developers) in the baremetal crates, not the ones which are based on top of ESP-IDF. Either because they consider the baremetal solutions more important, or because they think the ESP-IDF crates are in the meantime relatively mature, or both. Speculating here a bit, but that's the status quo. Therefore, the effort put into esp-idf-sys/hal/svc is based on mine (and others) free time. As in good will and so on.

Isn't it worth trying to found a real workaround ? like putting temporary files flatly in %TMP% ? Or any better idea?

Not sure for that suggestion. Might or might not work. If we go this route, we have to put not just build artefacts, but also the ESP IDF git repo itself in something like /tmp/<short-tmp-dir>. Another solution would be to make sure that ALL tools involved in building the esp-idf-sys crate itself as well as the ESP-IDF itself understand long paths, and if not - fix them. Perhaps possible, but definitely not easy. You also need to realize, that the "please use a short project path" restriction is coming from ESP IDF itself. It is just that the cargo build system is making it worse (as in the project path needs to be even shorter).

I've never seen this kind of problem with other chipsets supporting Rust...

Espressif's ESP IDF is unique in its class in that it provides you a Rust STD environment. On an MCU. Therefore, I think this "short project path" constraint on pure Windows (it does not exist with WSL2's native file system) is a small price to pay for that. Surely annoying, but tolerable. But then - IMO. Perhaps if you or other folks find this really inconvenient, you can work towards a solution?

It's better to use WSL2 as recommended and please refer this to bind the usb ports to the hosted linux distro -- things works like a charm :)

You are preaching to the wrong choir. I never said it does not work or that WSL2 is not a good workaround. If you would like to help, a paragraph to the README of esp-idf-template dedicated to Windows+WSL2, including some instructions what to install so that espflash works from inside WSL2 would be really, really appreciated.

[RingCanary]

Happy to help, will definitely do so over this weekend @ivmarkov.