Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
simpkins opened this issue May 3, 2024 · 1 comment

Comments

@simpkins
Copy link

simpkins commented May 3, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

2 participants