I'm trying to compile MPIR (Windows-friendly version of GMP). I have Visual Studio 2017 installed, so it should work, but I get this error message:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [C:\mpir\msvc\vs17\lib_mpir_gc\lib_mpir_gc.vcxproj]
I specifically need to get to a point where it can compile on any machine, not just this one, so installing that exact SDK version on this machine wouldn't solve the problem. I need to change something to get it to build with Visual Studio 2017.
Looking in C:\mpir\msvc\vs17\lib_mpir_gc\lib_mpir_gc.vcxproj, I find the line:
<WindowsTargetPlatformVersion>10.0.17134.0</WindowsTargetPlatformVersion>
Which looks promising, but deleting it has no effect whatsoever; the error message remains unchanged.
What can I change to eliminate this error?
To summarize my reason for believing this should be possible:
If you write a C++ program, say in the simplest scenario, in a single file called foo.cpp, and compile it with the commandline compiler cl foo.cpp it will automatically compile and link with whatever SDK version is used by the current Visual Studio install to generate foo.exe that will (unless you used some very specialized API only available in later Windows versions) run on any Windows from at least Vista on.
And that's exactly the same cl.exe that gets called by msbuild. So I'm not asking for new functionality. Rather, the above error message is being generated because something went out of its way to break the default 'it just works' scenario and add the lock to a particular SDK version. I'm asking how to remove the lock and get back to the default scenario where it just works with whatever SDK version Visual Studio came with.
As the comments state, this is unavoidable.
If you build with the Windows 8.1 SDK, you get a version that runs on Windows 8.1 or higher. If you build with the Windows 10 SDK, you can restrict its functionality to Windows 8, or you can pick a Windows 10 build (e.g. 1607). Of course, if you pick a new SDK to use new Windows 10 functionality, you can't run it on Windows 8.1 which misses that functionality.
But if you don't pick a Windows SDK, then what Windows version would you be building for? Which <windows.h> would you be using?
[edit]
As for portable C++ programs, they obviously don't include <windows.h>, and they don't link directly against the Windows API's. Instead, these take a dependency on Microsoft's implementation of the C++ Standard Library (aka MSVCRT)
[edit2] I just counted, My Visual Studio 2017 install (15.7.5) has 12 SDK different options. True, some are for ARM, but that's just a variation on the basic premise: the SDK you choose affects the machines on which you can run the resulting application.