Regression: Unstable "cargo:rustc-link-arg" no longer transitive

[ivmarkov]

Problem
A cargo:rustc-link-arg command issued from a custom build.rs script in a dependent crate used to bubble up all the way up to the final (binary) crate and be successfully used when linking the binary crate. This behavior was observed at least since V1.50 nightly, up until recently.

This change broke this semantics and the cargo:rustc-link-arg no longer reaches the final binary crate. Specifically, the key.0 == current_id check that was introduced on that very same line broke it.

I do realize that the semantics of bubbling up custom linker arguments from dependencies all the way to the final crate is a bit controversial in light of these comments, however I would argue that for embedded use-cases that might be a highly desirable behavior.

Case in point: our efforts to implement a cargo-first build for the ESP32 platform, which does link against the ESP-IDF C SDK of the vendor.

Before this change, we were able to nicely hide ALL the intricacies of downloading, building, generating Bindgen bindings for - and most importantly - linking with the ESP-IDF framework in a single crate - esp-idf-sys.

The philosophy is: simply depend on the esp-idf-sys crate (directly or indirectly) from your binary crate, and you get

• (a) unsafe bindings to the C API of ESP-IDF
• (b) automatic linkage of the ESP-IDF against your binary crate without leaving the Cargo build and without having to explicitly deal with CMake / PlatformIO / toolchain downloads etc. etc.

Steps
No easy steps to reproduce yet, but:

1. Follow the instructions here
   => Actual behavior: the build will fail with an odd error in "cargo-pio-linker" which is basically an indication that the cargo:rustc-link-arg flags are not propagated to the binary crate
   => Expected behavior: the build should succeed

Possible Solution(s)
a) Restore the old semantics, by removing the key.0 == current_id check
b) Introduce cargo:rustc-link-arg-transitive that would have the desired semantics
c) Have a declarative way for the binary crate to opt-in into getting link flags from a crate down the dependency chain

[ivmarkov]

Might be related to this issue.

[ivmarkov]

OK so I implemented a workaround by proclaiming that the SYS crate links against a library named "esp_idf" (such library does not exist but nobody seems to care), which allows me to "funnel" all the custom link args via an environment variable to the crates that DIRECTLY depend on the SYS crate.

The binary crate now depends directly on the SYS crate even though it does not consume its API at all, and has a nasty little build.rs script, whose only purpose in life is to unpack the "custom link args" environment variable and output it as a bunch ofcargo:rustc-link-arg statements.

All in all it works, but is too much equilibristic IMO. Having some sort of transitiveness of the custom-link-args stuff is cleaner.

[ehuss]

Thanks for the report! I think this is essentially a duplicate of #9554, so closing in favor of that.