`per-package-target` ignores target configuration

[mamins1376]

Problem

Using per-package-target without an explicit --target results in configuration specified in .cargo/config.toml keys relevant to the current compilation target being ignored, while specifying the same target explicitly would respect configuration.

Since I discovered this during development of an embedded arm project, I am using the same target (thumbv7em-none-eabihf) here, but I doubt that it matters.

Cargo.toml:

cargo-features = ["per-package-target"]

[package]
name = "per-package-target-run"
version = "0.1.0"
edition = "2021"
default-target = "thumbv7em-none-eabihf"

.cargo/config.toml:

[target.thumbv7em-none-eabihf]
runner = "echo"

Implicitly:

$ cargo run
   Compiling per-package-target-run v0.1.0 (.../per-package-target-run)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
     Running `target/thumbv7em-none-eabihf/debug/per-package-target-run`
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

Explicitly:

$ cargo run --target thumbv7em-none-eabihf
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running `echo target/thumbv7em-none-eabihf/debug/per-package-target-run`
target/thumbv7em-none-eabihf/debug/per-package-target-run

Steps

1. Download and extract the attached project: per-package-target-run.tar.gz
2. cd and compare running cargo run with and without --target ....

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.81.0-nightly (154fdac39 2024-07-07)
release: 1.81.0-nightly
commit-hash: 154fdac39ae9629954e19e9986fd2cf2cdd8d964
commit-date: 2024-07-07
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.8.0-DEV (sys:0.4.73+curl-8.8.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux [64-bit]

[soloturn]

why having per package targets does make sense, in general?

[mamins1376]

why having per package targets does make sense, in general?

In my workspace, there is one package for the ARM firmware, and one package for host app which communicates with the hardware running that firmware, plus one other shared crates for protocol description.

This kind of situation is common in embedded and/or microcontroller projects.

[weihanglo]

See #14833

Several places calling BuildConfig::requested_kinds don't consider anything from default-target or forced-target, so some target platform info may be missing.
...
The fix for the latter should be a bit easier. Managing all calls to requested_kinds through on a new requested_kinds method, which reuse a similar logic like this one. This should resolve the issue if only your top-level primary package has forced-target specified.

My feeling is that the scenario of the per-package-target feature is a bit overlapped. I am not sure whether we should reorganize them or have both separately.