search

rust-lang / compiler-team

A home for compiler team planning documents, meeting minutes, and other such things.
https://rust-lang.github.io/compiler-team/
Apache License 2.0
389 stars 69 forks source link

Promote OpenHarmony targets to Tier 2 with Host Tools #811

Open LuuuXXX opened 4 days ago

LuuuXXX commented 4 days ago

Proposal

Promote the following Tier 2 without Host Tools targets to Tier 2 with Host Tools:

Requirements for Tier 2 with Host Tools

Depending on the target, its capabilities, its performance, and the likelihood of use for any given tool, the host tools provided for a tier 2 target may include only rustc and cargo, or may include additional tools such as clippy and rustfmt.

rustc, cargo, clippy and rustfmt are required.

Approval of host tools will take into account the additional time required to build the host tools, and the substantial additional storage required for the host tools.

Maybe the infrastructure team will have to comment on this.

The host tools must have direct value to people other than the target's maintainers. (It may still be a niche target, but the host tools must not be exclusively useful for an inherently closed group.) This requirement will be evaluated independently from the corresponding tier 2 requirement.

There must be a reasonable expectation that the host tools will be used, for purposes other than to prove that they can be used.

These targets and host tools are intended for use by application developers on the OpenHarmony platform.

The host tools must build and run reliably in CI (for all components that Rust's CI considers mandatory), though they may or may not pass tests.

OK.

Building host tools for the target must not take substantially longer than building host tools for other targets, and should not substantially raise the maintenance burden of the CI infrastructure.

Yes.

The host tools must provide a substantively similar experience as on other targets, subject to reasonable target limitations.

Yes.

If the host tools for the platform would normally be expected to be signed or equivalent (e.g. if running unsigned binaries or similar involves a "developer mode" or an additional prompt), it must be possible for the Rust project's automated builds to apply the appropriate signature process, without any manual intervention by either Rust developers, target maintainers, or a third party. This process must meet the approval of the infrastructure team.

Currently works without a signature.

Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible.

There targets are already well-supported by cross compilation.

All requirements for tier 2 apply.

These targets are already supported in Tier 2.

Mentors or Reviewers

None listed

Process

The main points of the Major Change Process are as follows:

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

rustbot commented 4 days ago

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax: 

 @rustbot concern reason-for-concern 
 <description of the concern>

Concerns can be lifted with: 

 @rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

SparrowLii commented 2 days ago

That makes sense :)

@rustbot second