File path length in windows is quite tight with no mention in README

[parkero]

Hello! I am unsure whether this belongs more here or in esp-idf-sys, let me know if I should move it.

Using the documented install command of: cargo generate https://github.com/esp-rs/esp-idf-template cargo

Using defaults, and changing to the project directory, then: cargo build

compilation will fail in different ways, all on what would seem like "reasonable" path lengths ( <90 characters)

• Significantly too long: the longest individual esp-idf module clones fail to copy (silently)
• Too long: the compilation objects for tools will fail (cmake warnings)
• Just a little too long: the compilation objects inside esp-idf-sys<number>\out\build will fail

The longest build file path I encountered was: target\riscv32imc-esp-espidf\debug\build\esp-idf-sys-c62db9570d5f86ad\out\build\esp-idf\mbedtls\mbedtls\library\CMakeFiles\mbedcrypto.dir\9c79e945afe7d6d8afce1a1af409b8c0\esp_crypto_shared_gdma.c.obj.d which is 202 characters in length.

That leaves 58 characters (56 if building for release) available for (file path + project name) at a maximum.

A 90 character limit for esp-idf is documented here , along with a few other limitations regarding path characters.

It would be very nice to have

• this limitation documented here in the README.md
• if at all possible, an error message at (early) build time (probably falls under the purview of esp-idf-sys).
• the dream - use shortened path lengths for compilation objects. I know they ran into a similar issue over at bazel in 2017/2018

I would be more than willing to assist the process, but would probably need guidance for anything beyond the README; I am much more comfortable in Rust than C.

[ivmarkov]

I think anything beyond documenting this clearly in the README is either impossible or very difficult to implement. Given that esp-idf-sys is just shelling out to cmake + ninja, I'm at a loss how an early warning could be implemented. As for support for shortened path lengths not sure where even to start myself.

[parkero]

The README would be a clear improvement for sure.

Would anything prevent delivering an early message at either:

• download time: through the cargo-generate template using the {{os-arch}} placeholder in a conditional to display a message (source)
• build time: build.rs - using HOST and possibly CARGO_MANIFEST_DIR env variables set by cargo for build scripts (source)

[ivmarkov]

@parkero I think build time - and - specifically - when building esp-idf-sys is best, as it would work for any project, not just for ones generated by esp-idf-template.

Would you like to work on a PR for that?

[ivmarkov]

https://github.com/esp-rs/esp-idf-sys/commit/849149bd420165daf049c51f982dbae104fa9f97

[joelawm]

@ivmarkov I have been running into this issue on windows because of the <86 characters in the new build options. This option make the following fail which I think is a bit unreasonable. Error: Too long output directory: \\?\C:\ESP-32\target\riscv32imc-esp-espidf\debug\build\esp-idf-sys-940d9bcbde18e1cc\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! Is there a work around so I don't have to store the project code in the root of my file system?

[ivmarkov]

@ivmarkov I have been running into this issue on windows because of the <86 characters in the new build options. This option make the following fail which I think is a bit unreasonable. Error: Too long output directory: \\?\C:\ESP-32\target\riscv32imc-esp-espidf\debug\build\esp-idf-sys-940d9bcbde18e1cc\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! Is there a work around so I don't have to store the project code in the root of my file system?

I might have miscalculated the maximum allowed project length, so you might have some extra characters. Disable this build check and see for yourself.

Storing the project outside the drive root is pushing it though. As the message itself says, using WLS2 is the only feasible workaround for now.