More granual `build.rs` companion: `link.rs`

The problem

Click to fold (click for more details)

Palliatives / working around it with the current tools

Click to seeRelevant snippet from my rust-analyzer config (click for more details)

The suggested solution

Would be for Cargo to fully acknowledge and embrace this package.links with a companion build script (the "conceptual links.rs build script"), and reïfy this concept :

1. Allow for package.links to be set to an object rather than just a string, with, at least:

   • name entry, to be set to its identifying name,
   • script entry: to be set to point to some .rs file.
     • Optionally, it could be set to true to default to links.rs; and/or having such a file alongside a Cargo.toml and a links = "libfoo" kind of entry could be tantamount to all this.

[package]
links = { name = "libfoo", script = "links.rs" }

1. Such a links.rs-specified Rust file shall:

   • be interpreted like a build.rs does currently in Rust:

     • involving build-dependencies,
     • living in the build/host universe (e.g. , w.r.t. Cargo resolver or whatnot);
     • being bypassable through links overrides (the build.rs being the one bypassed as a fallback , for retro-compat).

   • but only involved:

     • for actual cargo-compiling commands, such as build/run/test/bench, i.e. , it would be skipped when runningcargo check/clippy/doc.
     • invoked in the tail-end of the compilation pipeline.

Or, more precisely, deemed to have no dependents inside Cargo pipelining but for the compilation/linkage of the very final artifact(s) (which cargo check/clippy/doc do not produce).