Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support generic target tables and env variables #14264

Open
jameshilliard opened this issue Jul 18, 2024 · 4 comments
Open

support generic target tables and env variables #14264

jameshilliard opened this issue Jul 18, 2024 · 4 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@jameshilliard
Copy link
Contributor

jameshilliard commented Jul 18, 2024

Problem

When building for targets from a meta build system like buildroot it is preferable to be able to unconditionally set target config/env variables without having to care about the target triple as we use target specific toolchains that will only support a single target architecture typically.

Proposed Solution

#9603

@jameshilliard jameshilliard added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Jul 18, 2024
@epage
Copy link
Contributor

epage commented Jul 18, 2024

The linked PR doesn't provide much details on the proposed solution besides a code dump. Could you provide more details on the problem, what the user-facing solution would be, and how that helps?

@jameshilliard
Copy link
Contributor Author

jameshilliard commented Jul 18, 2024

Could you provide more details on the problem, what the user-facing solution would be, and how that helps?

Currently to say set a target linker we have to generate an env variable like CARGO_TARGET_$(call UPPERCASE,$(RUSTC_TARGET_NAME))_LINKER, it would be nice to be able to set the target linker for all target artifact builds using a non-target-triple specific variable like CARGO_TARGET_LINKER.

@epage
Copy link
Contributor

epage commented Jul 18, 2024

In TOML terms,

[target]
linker = ...
[target.<triple>]
linker = ...

translates to

{
    "target": {
        "linker": "...",
        "<triple>": {
            "linker": "...",
        }
    }
}

Personally, I would worry about putting target-config fields at the same level as <triple> / <cfg>

Some options

  • built-in value that means "all"
  • extend which fields can be used with <cfg> (I'm assuming there are technical limitations for this)

Huh, we don't specify what happens if multiple targets apply. In moving this forward, we should probably verify what is done in that case and be able to talk whether a design for solving this problem works with that solution or not.

@jameshilliard
Copy link
Contributor Author

Huh, we don't specify what happens if multiple targets apply. In moving this forward, we should probably verify what is done in that case and be able to talk whether a design for solving this problem works with that solution or not.

So in my pull request I actually wrote a test to cover this specific scenario. The way I implemented the logic was to have any target triple specific configs take precedence over generic target configs if they exist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants