Skip to content

Rework run-make-support's target to be a structured API #148747

@jieyouxu

Description

@jieyouxu

run-make tests often need to have target-specific behavior (or have a distinction between host / target). We should make support for that properly structured and not via substring matching. E.g. instead of the various is_windows_msvc and target helpers, introduce a structured target API:

fn host() -> TargetInfo;
fn target() -> Targetinfo;

#[non_exhaustive]
pub struct TargetInfo {
    pub target_tuple: String,
    pub arch: Arch, // possibly with a subarch too
    pub env: Env, // with a Env::None
    pub os: Os, // with a Os::None
    pub vendor: Vendor, // with a Vendor::None
    pub target_family: TargetFamily, // with a TargetFamily::None
}

Also, consider changing the run-make test <-> run_make_support <-> compiletest env vars to be prefixed as internal-only, then only "publicly" expose this to run-make tests.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-run-makeArea: port run-make Makefiles to rmake.rsA-testsuiteArea: The testsuite used to check the correctness of rustcC-enhancementCategory: An issue proposing an enhancement or a PR with one.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions