It doesn't work in cmd.exe

[Boscop]

I tried it in cmd.exe, it didn't work:

error: failed to run custom build command for `myproject v0.1.0 (file:///D:/projects/myproject)`
process didn't exit successfully: `D:\projects\myproject\target\release\build\myproject-fec71028c365cf09\build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { cod
e: 2, kind: NotFound, message: "The system cannot find the file specified." }',
libcore\result.rs:945:5
stack backtrace:
   0: std::sys::windows::backtrace::unwind_backtrace
             at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:65
   1: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
   2: std::sys_common::backtrace::print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:59
   3: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:211
   4: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:227
   5: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:463
   6: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:350
   7: std::panicking::rust_begin_panic
             at C:\projects\rust\src\libstd\panicking.rs:328
   8: core::panicking::panic_fmt
             at C:\projects\rust\src\libcore\panicking.rs:71
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: std::rt::lang_start_internal::{{closure}}
             at C:\projects\rust\src\libstd\rt.rs:59
  13: std::panicking::try::do_call<closure,i32>
             at C:\projects\rust\src\libstd\panicking.rs:310
  14: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:105
  15: std::panicking::try
             at C:\projects\rust\src\libstd\panicking.rs:289
  16: std::panic::catch_unwind
             at C:\projects\rust\src\libstd\panic.rs:374
  17: std::rt::lang_start_internal
             at C:\projects\rust\src\libstd\rt.rs:58
  18: main
  19: invoke_main
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:64
  20: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  21: BaseThreadInitThunk
  22: RtlUserThreadStart

warning: build failed, waiting for other jobs to finish...
error: build failed

Maybe it can't find the winsdk or rc.exe from the registry?

Btw, the winres crate worked...

[FaultyRAM]

Trying to rule out the possibility that there's something funky going on with your build environment, so bear with me here:

• What Windows SDK do you have installed?
• Are you running this from plain old cmd.exe, or a Visual Studio Command Prompt?

[Boscop]

I have Windows sdk 8.1.
Plain old cmd.exe.
Shouldn't this crate be able to find the location of the sdkl through the registry? :)

[FaultyRAM]

It does, by querying HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\[SDK. version], which is redirected to Wow6432Node on 64-bit Windows. (winres uses a different key, but AFAICT that one doesn't distinguish between versions). Apparently in the past, a similar subkey was created under HKCU, but IIRC modern installs don't do this anymore - could it be that you don't have the HKLM subkey but do have the HKCU one?

[Boscop]

Hm, apparently I have the HKLM key (but not the older HKCU key):

[FaultyRAM]

Ah, I see now. This is an earlier a different version of the Windows 8.1 SDK, as indicated by the A suffix (the one that ships with Visual Studio 2017 doesn't have this). find-winsdk doesn't check for these right now, only v10.0 and v8.1. Fixing this should be pretty simple, although we won't be able to test for it on CI because, at least when using the VS2017 image, older versions of the Windows SDK aren't pre-installed on AppVeyor.

[FaultyRAM]

windres 0.2.1, which addresses this issue, is published on Crates.io. Could you run a cargo update and see if it works?