Per chip configuration?

[MabezDev]

Part of the problems found in https://github.com/bjoernQ/rconfig/issues/1 would be solved if we also supported a per chip configuration system.

It might work something like:

• rconfig.toml - assumes this config is for the selected chip features
• rconfig.esp32.toml - if esp32 is the selected chip feature it will read this feature
  • should it also concat rconfig.toml? not sure

[bjoernQ]

That's an interesting idea 👍

[bjoernQ]

I thought about this idea a bit. From a user's perspective that would be very nice but not sure how to implement that

• given a crate, e.g. esp-hal or esp-wifi will read "their part" of the config I wonder how to know which config file name to look for
  • in our case usually all our crates have a feature to select a chip but that's a very hard assumption (i.e. the library won't be generally usable outside our own crates if we assume that - which is probably fine but ideally the library should be "general purpose")

Things would probably get easier if we had a config file per crate - e.g. esp-hal.config.toml and then we could just look for variants containing the selected feature(s) e.g. esp32c6.config.toml. But then thing will become a bit "harder" for the TUI

Another thing that comes to my mind while writing this: What if a config value couldn't depend on a feature? i.e. depends can only reference other options. We would have a new key like active-when which limits the effect of the config value to only features / feature combinations. When reading the user's config, we could still emit a warning that the config value isn't in effect and in the TUI/GUI we would show inactive options e.g. in light gray but the user can still change them.

That means a user could configure PSRAM options also for e.g. C6 and PSRAM-TYPE also for e.g. ESP32 but the value is only in effect when the feature is used in the build. If I'm not missing something very important here this idea sounds like a good idea 🤔

.... oh wait .... you wrote rconfig.toml not config.toml - so not sure anymore if we are talking about the user's configuration values or the configuration definition file? 🤔 But I guess we are talking about the user's configuration values?