RFC: Add target configuration

[GuillaumeGomez]

This is taking over #2991 by adding the missing part requested by @joshtriplett here.

rendered

[GuillaumeGomez]

Updated!

[jfrimmel]

Recently I hit exactly the problem described in the rationale of the RFC. I currently also use the build.rs-based workaround.

Therefore 👍

[nvzqz]

I have closed #2991 in favor of this PR. Thank you @GuillaumeGomez for taking it over for me.

[GuillaumeGomez]

Thanks for the trust @nvzqz!

[GuillaumeGomez]

Is there anything else to be done in here?

[joshtriplett]

I think this has now addressed all of the feedback from the previous thread; let's see if we have consensus on it:

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[CryZe]

The main motivation here seems to be that target_abi isn't stable and that matching against many components isn't ergonomic, which #[cfg(target(os = "linux", arch = "arm"))] would make quite a lot more ergonomic. Given all that, is there sufficient motivation to not just stabilize both of these and postpone / split out the rest?

I'm saying this because comparing the exact string literal seems very prone to crates "overusing" this and thus accidentally being incompatible with targets that they should be compatible with. This is a major drawback. I've experienced this multiple times in the ecosystem where crates accidentally only supported a single WASM target, completely forgetting that there's more than just one. I'm thinking matching against the full triple name without any support for wildcards would therefore be quite a footgun.

The RFC seems also not entirely clear in whether the triple is parsed and then compared semantically or if it's truly just a string comparison. The latter would be even more problematic (e.g. wasm32-wasi initially contained -unknown- for a few releases, also what about other Rust compilers that might not use the exact same target names?).

Also I just checked where the main motivation for this is coming from: The log crate, which seems to have trouble figuring out whether atomics are available on the target. Yet again, there's various unstable target cfgs available for that, that need a push for stabilization, matching against the specific target name is the wrong solution to the problem (unless I'm missing something at first glance).

[joshtriplett]

Also I just checked where the main motivation for this is coming from: The log crate, which seems to have trouble figuring out whether atomics are available on the target. Yet again, there's various unstable target cfgs available for that, that need a push for stabilization, matching against the specific target name is the wrong solution to the problem (unless I'm missing something at first glance).

That isn't the only motivation. Log should absolutely use the atomic configs, rather than this, but this still has value.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[GuillaumeGomez]

Updated.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[ehuss]

@GuillaumeGomez or @pnkfelix Can you post a PR to update the issue link to rust-lang/rust#96901?

[GuillaumeGomez]

On it.