Windows: Cannot build

[SkyLined]

I am trying to build x64 Debug ChakraCore from source, here's my setup:

• Windows 10.0.14393
• Visual Studio 2015 Pro 14.0.25431.01 Update 3
• Windows SDK 10.0.15063.468
• I've checkout the most recent source using git in the folder P:\dev\ChakraCore

(Note that I have build ChakraCore on this machine successfully before, but that was just over a month ago. Because the build failed, and I was unable to fix it, I deleted all the files in ChakraCore source folder and downloaded them again using git. After it still failed, I try "repairing" my Visual Studio install and removed and reinstalled the Windows SDK. Despite all this, I am still unable to build.)

For brevity, I will only include the first error I see:

1>------ Build started: Project: Chakra.JITIDL, Configuration: Debug x64 ------
2>------ Build started: Project: CoreManifests, Configuration: Debug x64 ------
3>------ Build started: Project: wabt, Configuration: Debug x64 ------
4>------ Build started: Project: Chakra.Common.Codex, Configuration: Debug x64 ------
5>------ Build started: Project: Chakra.Common.Util, Configuration: Debug x64 ------
6>------ Build started: Project: Chakra.Common.Exceptions, Configuration: Debug x64 ------
7>------ Skipped Build: Project: pal, Configuration: Debug x64 ------
7>Project not selected to build for this solution configuration 
8>------ Build started: Project: rl, Configuration: Debug x64 ------
1>Build started 04-07-2017 18:05:54.
1>     1>
1>InitializeBuildStatus:
1>         Touching "P:\dev\ChakraCore\Build\VcBuild\obj\x64_debug\Chakra.JITIDL\Chakra.JITIDL.tlog\unsuccessfulbuild".
2>Build started 04-07-2017 18:05:55.
1>     1>
1>TRACKER : error TRK0005: Failed to locate: "midl.exe". The system cannot find the file specified.

It appears that midl.exe cannot be found. This is part of the Windows SDK and can be found on my computer in the following locations:

C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\arm64\midl.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\midl.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86\midl.exe

I have no idea why it cannot find this file; can anybody explain why it would not be able to find it even though it is right there in the location where you would expect it to be?

[MikeHolman]

I think VS looks for midl based on some environment settings, which you can see in the project settings. This is what I have for x64debug build: $(VC_ExecutablePath_x64);$(WindowsSDK_ExecutablePath);$(VS_ExecutablePath);$(MSBuild_ExecutablePath);$(FxCopDir);$(PATH);

You might try building with verbose output to see what these are set to. WindowsSDK_ExecutablePath should have a folder with midl in it. This is what I see on my machine: WindowsSDK_ExecutablePath = C:\Program Files (x86)\Windows Kits\8.1\bin\x86;;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools

[obastemur]

Windows 10.0.14393 Windows SDK 10.0.15063.468

Is it possible that the issue here is not having the SDK for Windows version? I remember having a similar problem in the past.

[SkyLined]

I have a similar value for WindowsSDK_ExecutablePath: C:\Program Files (x86)\Windows Kits\10\bin\x86;;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools. However, there are no binaries in the folder C:\Program Files (x86)\Windows Kits\10\bin\x86; midl.exe can be found in C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86. So could it be that this path was not set correctly during installation of the WDK? Do you know where this value is specified in Visual Studio, so I can update it?

[SkyLined]

For future reference, you can enable "verbose output" through the Visual Studio menu: Tools > Options > Projects and Solutions > Build and Run: under MSBuild project build output verbosity select Diagnostic.

[MikeHolman]

On my machine I do see midl under C:\Program Files (x86)\Windows Kits\10\bin\x86 as well as C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86

I think the define is coming from here (or similar): C:\Program Files (x86)\Microsoft SDKs\Portable\v15.0\DesignTime\CommonConfiguration\Neutral\windows.props (which is reading it from the registry). Seems scary to change though, so I might advise trying to reinstall the win10 sdk, since it seems like something is wrong there.

[MikeHolman]

Also, if that doesn't work I suggest you try installing the win8.1 sdk if you don't have it. Possible there is some dependency on having that.

[SkyLined]

Thanks, for the help. As explained in the bug report, I already tried reinstalling the win10 sdk, which did not fix the issue.

I just tried installing the Windows 8.1 SDK and that did not change anything either.

I have a similar windows.props file on my system and it does refer to the registry (through a few other variables it ends up reading and using HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1A@InstallationFolder to set the WindowsSDK_ExecutablePath_x86 and WindowsSDK_ExecutablePath_x64 values). However, it does not set WindowsSDK_ExecutablePath itself and that registry key contains the value C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\, but I am seeing the value C:\Program Files (x86)\Windows Kits\10\bin\x86;;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools in Visual Studio. As such, I do not believe that is where the value comes from. Btw. I have no fear of changing registry settings; such changes are easy to reverse and if I cannot fix this build, I am probably going to have to completely reinstall my system anyway, which I'd really, really like to try and avoid given how much time it'll take to get everything set up again.

[MikeHolman]

I think there should be a similar path to that for win10, but not sure exactly how VS figures it out. But the platform specific variables eventually gets combined to the architecture independent one inside: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Common.props

[kevingosse]

For reference, I just ran into this issue. It seems to be specific to the version 15063 of the Windows 10 SDK. Uninstalling it and switching to version 10586 fixed it.