Another concern about using cfg: Doing so makes it really hard to enumerate/list all "supported" variants. Places where this would be useful:
- Filtering crates based on whether they support a specific (or set of) targets. While this would be possible with
cfg, doing so would be harder and its thus less likely to be done - Doing a task for every supported configuration. For example running all tests on all targets or compiling a binary for all "supported" targets. With a simple list that doesn't contain
cfgthis is really easy, but as soon ascfgis involved you additionally need to bother with parsing it and it can make it hard to see which configurations are included. You may have to iterate a list of all possible target-tripple + feature flags + ... combinations just to enumerate them or you need more complex logic to reduce that set.
I think the usefulness of easy enumeration and ease of parsing/doing so should not be underestimated. cfg is good at saying yes or no, but I don't think that's enough here.
Personally, I think doing it in toml is better than using cfg, for example:
[[lib.supported-configurations]]
targets = ["wasm32-unknown-unknown", "wasm32-wasi"]
required-features = [] # Enabled automatically when compiling for that target
[[lib.supported-configurations]]
# Can be extended with wildcards
target = ["*-linux-*"]
[[lib.supported-configurations]]
# If there is a desire to further group targets together
# (to reduce the amount of typing)
target_os = ["windows"]
Assuming per-target required features should be represent-able configurations probably makes more sense and avoids the target renaming discussion
Another advantage of doing it this way would be that it can be extended more easily. For example: With cfg you might have a hard time adding an extra (optional) support_level field in the future (similar to the levels of rust target support). Even with the basic list-of-strings such extendability is not possible or at least harder to do in a backwards compatible way.