Reminder: custom target specification is a target platform description similar to those in
src\librustc_target\spec, but passed dynamically as a json file using
--target option with a file argument is available on stable Rust, so it would be reasonable to expect that stability of the target spec format is controlled by some policy.
However, I haven't seen this mentioned anywhere (not in https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md in particular), except for some people in chats occasionally.
In practice, new fields are added to the target specification very liberally without any official approval and are usually treated as implementation details.
I've seen fields removed as well, but that happens very rarely.
I'm bringing this up because I want to add a few new field related to linker behavior, and migrate some old linker-related fields to them (this may take multiple PRs/weeks/months), but the end state is not entirely clear until the migration is complete.
I wonder if I should introduce some notion of "unstable" custom target spec options and emit an error if they are constructed from a json file on stable channel, or maybe that's an overkill.
Example of a PR removing some target spec fields - https://github.com/rust-lang/rust/pull/71001.
But those fields were added, like, two weeks ago :slight_smile:
I think we've treated spec files as essentially unstable, you can't practically change things and use them on stable, right? Since you need to build at least core...
I've always assumed they were unstable (which is what I was told a while back). Should we make the --target flag unstable when used with a json spec?
@Amanieu Seems like a good idea to make it unstable; I've also always assumed it as unstable
That seems reasonable, yes, though I imagine we'd want to phase it in similarly to -Zunstable-options a year or two back
mostly so that people using it have some time to complain, and we can upstream their target files or at least know we're breaking people
@simulacrum Sure; do you think you have the time to file an issue for this?
Not right now no
I can do so in an hour or two though
I think we've treated spec files as essentially unstable, you can't practically change things and use them on stable, right?
You can take an existing target and, for example, change only something affecting linking of dlls/executables.
Something like e.g. linking
glibc statically (disclaimer: I didn't try it). libcore and libstd are can be reused without changes as static libraries in this case.
Well, I guess in practice people don't do that?
I've heard people mostly tweak the target specs for embedded use cases where you have to rebuild everything anyway.
Yes, its one of those things that are only de-facto unstable.
Would be good to make it properly unstable (require -Zunstable-options).
Posted it to #rust-emdedded:matrix.org just to let people know
#rust-emdedded:matrix.org does not exist.
This room doesn't exist. Are you sure you're at the right place?
(I see the typo tho)