esp-rs / rust

Rust for the xtensa architecture. Built in targets for the ESP32 and ESP8266
https://www.rust-lang.org
Other
742 stars 39 forks source link

set chip name in the target family or target vendor setting for no_std targets #221

Open simpkins opened 6 months ago

simpkins commented 6 months ago

This is a feature enhancement request: would it be possible to set the chip name in the target family or target vendor field for the no_std targets?

This seems like it would make it much easier to enable conditional compilation based on the chip type. Currently this is done with features, and it seems to get pretty awkward to have to define chip-specific features for all chips your crate might support, and then explicitly propagate them through to all other dependencies that need them (e.g., esp-hal, esp-storage, esp-wifi, esp-backtrace, esp-println, etc.) You end up with stuff like this, and it has to be repeated in many different crates.

Having the chip type available in the target_family or target_vendor seems like it would simplify this significantly.

It seems like this would be pretty easy for the xtensa based chips, since there is already a separate target for each chip type (e.g., xtensa-esp32s3-none-elf, xtensa-esp32s2-none-elf, etc.). The riscv based chips don't appear to currently have per-chip targets, but maybe it would be worth adding them if it let us avoid having to repeatedly specify chip features in lots of separate crates?

The xtensa targets appear to put the chip name in the "vendor" portion of the target triple, so it seems like maybe the target_vendor field should be set to the chip name? (The espidf targets happen to already set the vendor to espressif, but the no_std targets currently leave it empty.)

MabezDev commented 5 months ago

This is a really neat idea. I would like this a lot!

There are some limitations with what you can cfg and where when it comes to .cargo/config.toml and Cargo.toml, we should explore whether this approach would be affected by those limitations.

I already maintain many of the upstream RISC-V targets, so I think adding Espressif-specific ones wouldn't be so bad - but it might be a bit of a chore to get them bumped to tier 2.