ivmarkov

@georgik I think you are (unfortunately) probably right in the following: the _absence_ of the app manifest does **not** mean, that the app is incompatible with long paths! It might...

> All tests were done with enabled LongPath registry. BTW: Windows [idf-installer](https://github.com/espressif/idf-installer) has check and sets this registry, this behavior was added long time ago. > > Tests were conducted...

By the way what you (and I) call a "UNC" path, and what you've used in your example is called _"verbatim"_ path in [this table](https://github.com/rust-lang/cargo/issues/9770#issuecomment-993069234). Not that this is an...

> BTW: Windows [idf-installer](https://github.com/espressif/idf-installer) has check and sets this registry, this behavior was added long time ago. I don't think folks using the `esp-idf-*` crates are using the Windows `idf-installer`...

I'm quite busy this week so realistically I can provide feedback on the PR will next week. To set the expectations - some changes - mainly de-stdfication as esp-idf-svc is...

> ~ ah i got bamboozled by the github ui ... it was the cmake ci where the no_std build fails not the cargo ones... RIP me. ~ > >...

By the way the recently committed PR for the i2c clock does not build on the c2. You might want to look into it.

It seems that esp idf itself fails (gccs eh_alloc.cc) and seems to be a linking issue in esp idf itself. Weird how it links with an `idf.py` build...

> the c2 issue was already on my radar, i created issues on esp-idf-hal, one of them is an easy fix, the other i have to think about a bit....

> @ivmarkov thinking about it again, we could remove the v4.4 option in the advanced path now. What do you think? What is this giving us?