Autodisovery of xtensa toolchain

[sansmoraxz]

Just like how MSVC path is automatically detected same may be done for xtensa. As of now to build properly I need to run:

PATH="$HOME/.espressif/tools/xtensa-esp-elf/esp-15.1.0_20250607/xtensa-esp-elf/bin/:$PATH" cargo build

or activate the esp idf env which configures all these envs, include paths, etc.

Or some sort of optional coupling may be done with embuild

viz inside the cargo workspace dir .embuild/espressif/tools/xtensa-esp-elf/esp-13.2.0_20240530/xtensa-esp-elf/

[sansmoraxz]

cc @Vollbrecht @ivmarkov

[ivmarkov]

I'm not sure the minor extra ergonomics you'll get from that are worth the effort.

[Vollbrecht]

I will give a bit of context to exapand on the answer from ivmarkov.

We currently try to avoid manually playing with PATH env variables as much as possible and keep it dynamic depending on the project configuration.

Env pollution can be a real problem, especially if you have potentially having multiple projects that started at different times and use different esp-idf versions. That's why all compile runs define for there compile lifecycle the necessary env/path variables to the correct tools.

Why such a complicated solution you may ask? Well we need to make sure that for the current targeted ESP_IDF version only see the supported tools and not some to new/old versions. Same goes with later linking the rust and esp-idf library together.

In general we allow the user to select from different kinds of esp-idf ( and associated tools) installations. From fully managed to bring it all yourself. More info on that options are found here.

With this info in the background, if the installation is a "managed" one than stuff like correct PATH variables are all set correctly automatically for the lifetime of the compilation.

If the user choose to bring everything by themself, than yes, one would have to for example define the PATH correctly. But this comes at a potential big problem. The user needs to be aware that they now - for every project from now on that they work on - needs to manually make sure to align the provided env/path's such that a) it always include only "correct" versions of the tools for that esp_idf version they work against b) make sure that not another tools version is leaking into the current compile run.

In this above situation its easy to make mistakes. That's why by default we do this "fully managed" approach. But yeah sometimes magic is just to much magic and we need see if we need to re balance our approach.

Hope that gives a bit of background on the situation from our point of view.

[NobodyXu]

Note that we do support CC_{target} and CFLAGS_{target}, so if you are changing PATH, might as well use CC_{target}?

[sansmoraxz]

I am thinking we could use the methods for fetching as used in: https://github.com/esp-rs/esp-idf-sys/blob/master/build/common.rs. Maybe a crate spinoff, or duplicated here.

Would work for most scenarios except for a potential build script race of the idf-svc and cc.