Only use metadata for current target

[jonhoo]

Unlike most other cargo tools, cargo metadata counter-intuitively defaults to downloading all dependencies for all targets unless the argument --filter-platform is passed. This means that with the current logic, cbindgen ends up downloading potentially a very large number of dependencies whenever this is invoked:
https://github.com/eqrion/cbindgen/blob/93eed3aaf3a6ed94ae5bdf59e5df4c508fe05a5b/src/bindgen/cargo/cargo_metadata.rs#L189-L194

Since cbindgen doesn't actually need the dependencies themselves (I don't think), I believe cbindgen should probably always specify --filter-platform, and just specify the host platform. Cargo finds the host platform by running rustc -Vv and extracing the host: line, which cbindgen could probably also do pretty easily:
https://github.com/rust-lang/cargo/blob/fde8ee3ba0cba4eef75f197d42586ef4664f057b/src/cargo/util/rustc.rs#L48-L68

This is also what rust-analyzer recently switch to doing: rust-lang/rust-analyzer#6912

There's also precedent for relying on rustc to determine these kinds of things, such as using it to find the sysroot:
https://github.com/rust-analyzer/rust-analyzer/blob/48802e54d1669c68fd27b007533dd6aa5221d089/crates/project_model/src/sysroot.rs#L126-L127

One way to make this nicer would be if cargo metadata supported a "special" value for --filter-platform called host. I'll look at submitting that as a PR upstream, but the more immediate fix (and also one that would continue to work for older compiler releases) would be to just use rustc -Vv.

[jonhoo]

Note also that even if --filter-platform is set

the dependencies listed in the "packages" array still includes all dependencies. Each package definition is intended to be an unaltered reproduction of the information within `Cargo.toml.

(from cargo help metadata)

[emilio]

Seems sensible :)

[jonhoo]

PR coming in a few minutes ;)

[jonhoo]

Digging some more, it looks like cbindgen explicitly wants to recursively process into the source of the dependencies here:
https://github.com/eqrion/cbindgen/blob/93eed3aaf3a6ed94ae5bdf59e5df4c508fe05a5b/src/bindgen/parser.rs#L164-L173

It appears as though that code wants to have the source of all dependencies across all cfgs available regardless of what the cfgs currently are, which is fundamentally incompatible with only fetching the needed sources for the target platform. And I suppose it makes sense that cbindgen actually needs the cross-target sources, as otherwise it wouldn't be possible to expand something like

#[cfg(linux)]
pub type X = libc::something;
#[cfg(windows)]
pub type X = winapi::something;

into the expected pair of #defines on any platform as either the libc or the winapi source would be unavailable.

That's unfortunate, but feels like there isn't really a way around. Alas, I guess this then has to be closed then. It's unfortunate, because this logic applies to all dependencies regardless of whether they are actually used in the code that bindings are generated from. For example, if a user has criterion listed in dev-dependencies, the current logic will always have cbindgen download wasm-bindgen no matter what the user's platform is...

[emilio]

dev-dependencies are a different story though, right? They should probably be excluded, that's #666. I think having this be opt-in somehow would be fine, if somebody needs it. It's reasonable if you generate bindings at build-time.

[jonhoo]

@emilio I filed #676 which defaults the behavior to only downloading for the current platform, but introduces a configuration option to get the old behavior.