search

nabijaczleweli / rust-embed-resource

A Cargo build script library to handle compilation and inclusion of Windows resources, in the most resilient fashion imaginable
MIT License
166 stars 29 forks source link

expose tool finding mechanism in public api #24

Closed mcgoo closed 3 years ago

mcgoo commented 3 years ago

This is an implementation of what I was suggesting in https://github.com/nabijaczleweli/rust-embed-resource/issues/23.

There are a lot of other tools that are hard to find in the same way rc.exe is. In my case I need the same logic for midl.exe.

This should build for non windows-msvc targets and return no path, which seems consistent with the internal behavior of find_windows_sdk_tool.

I realize this might be out of scope or otherwise uninteresting. Thanks for taking the time to consider it, and thanks for embed-resource, it could hardly be more convenient.

mcgoo commented 3 years ago

Hmm. The -gnu tests fail because the doc test uses vswhere (because midl.exe needs cl.exe). I could add a build dependency on vswhere, or change the example to something other than midl.exe. What do you reckon?

nabijaczleweli commented 3 years ago

I've updated the PR with a clean-up commit, if you could look through it and sign off on the (mostly cosmetic) changes, then this'll be good to merge.

As for the vswhom issue, I resolved that by wrapping the entire doctest in #[cfg(all(target_os = "windows", target_env = "msvc"))], works for me, so should work on AppVeyor too.

mcgoo commented 3 years ago

Looks good to me, thanks.

(Do you have a custom rustfmt or something? I get a bunch of warnings about rustfmt.toml parameters and a big diff if I run cargo +nightly fmt).

nabijaczleweli commented 3 years ago

Cool, squashed into f3f07c01c19100591903985d8ef47fa1c86568cf.

And, no, I just have an old one (nominally, rustfmt --version returns 0.7.1 (), but this cannot be trusted), for precisely this reason; don't worry about the formatting.

nabijaczleweli commented 3 years ago

Released in v1.4.0. Thanks!