.windows folder: Why based on "first $PATH entry" and not "$OUT_DIR"?

[EndilWayfare]

In exploring the feasibility of migrating my Rust bindings for some proprietary, 3rd party software from winapi to windows, I noticed that I would need to turn the .tlb files I winapi-tlb-bindgen'd before and somehow turn them into .winmd files, per #928 (comment).
I would prefer to generate the .winmd in a build script, from .tlbs scraped from the actual installation folder of the other software, because their licensing is a bit hazy. It says "Subject to the license terms for the software, you may redistribute the following .DLL files unmodified:", and it doesn't say anything about redistributing the .tlbs. I think there's a compelling case that translating .Net dlls into .winmd isn't "modifying", since the behavior is the same and just described in a different way. PLUS, the .winmd (and the .tlb before it) are basically glorified header files, describing interfaces (theoretically reconstructable from publicly available API docs) and not containing implementation. Regardless, I'm erring on the side of playing it safe and not redistributing if I don't have to. Preferably, the translation should be done in a way that only uses Rust build-dependencies and/or VS dev tools, so that consuming crates can build without other weird dependencies.

So I wondered if I could generate .winmd files in build.rs,

and stick them where windows could pick them up. Per #93 (comment), you can stick 3rd party metadata in a ".windows/winmd" subfolder in the folder containing your Cargo.toml. So far so good, only that's outside the transitory "target" folder and I understand that build.rss aren't supposed to modify stuff that isn't a build artifact. (Technically, they shouldn't modify anything outside of $OUT_DIR...) I looked at the implementation of build! to see if I could understand how the ".windows" folder fit into the machinery. Aha! It copies stuff from the source ".windows/winmd" folder to "target/.windows/winmd"! Cool, so hopefully I can dump .winmds in there, put the .dlls in an analogous sibling architecture folder, slap a "cargo:rustc-link-search" on it and call it a day.

But how do you get that folder location?

build! gets it by grabbing the first &PATH path and popping from it. That seemed rather odd to me at first. TIL cargo prepends "target/{profile}/deps" to $PATH when compiling.

Oh wait, the copying happens after windows.rs is already built. Some more digging later, I determined that the actual metadata-finding happens in windows_gen and it defines one of its search paths equivalently to target_dir in build!, but it also defines another search directory in terms of "target" folder. 9 times out of 10, those are going to be the same folder, I think, unless you're cross-compiling (maybe x86 on an x86_64 machine?). Even then, the metadata is platform agnostic. I don't understand why you'd need a copy in there. Unless... does Windows sometimes use the metadata at runtime?

If that's the case, I should... probably mimic the copy logic in build!?

[EndilWayfare]

#979
Dang it, I'm an idiot.

I wrote this issue as I was working through the process of understanding what's going on, and now I can recognize that "cross-compiling" and "path not ending in ;" are super related, even though it's not immediately apparent.

[kennykerr]

Yes, sorry for the confusion. I plan to address the bigger issue shortly. There was an attempt to support binary packaging transitively but that doesn't work well with Cargo at the moment. So we'll go back to the simpler model of having an explicit .windows folder in each crate/workspace that wishes to contribute binaries. We may revisit this in future. @riverar

[EndilWayfare]

Yeah, I was running into a similar complication with gtk-rs. They're using Meson to do the post-cargo resource wrangling.