Then in the project directory I execute these two commands:
set SDKROOT=%SystemDrive%/Library/Developer/Platforms/Windows.platform/Developer/SDKs/Windows.sdk
set SWIFTFLAGS=-sdk %SDKROOT% -resource-dir %SDKROOT%\usr\lib\swift -I %SDKROOT%\usr\lib\swift -L %SDKROOT%\usr\lib\swift\windows
And last I try to build into an executable, which is when I get the errors in the screenshot.
Swift is installed ( swift --version returns what is expected).
The error I'm getting says that SwftShims can't be built because the file stddef.h is not found. But the file is there. Apparently this same error gets thrown on certain version of Ubuntu, but I'm not sure how to fix this. I posted a log below where I tried to execute swift main.swift. I know this isn't supported yet, but it gives me the same errors as when I try to build, but in a much more readable format.
I hit this error all the time when compiling for Android and it's because the symbolic link to the clang headers isn't set right. Check your Swift resource directory at %SDKROOT%\usr\lib\swift: is there a clang/ directory or link and does it contain or point to a directory with stddef.h? I don't know if Windows works the same way in this regard, but that's where the Swift compiler looks for that header on other platforms.
The problem is the missing flags. You need to indicate where the SDK is. You can use the convenience environment variable that is added by the installer: SDKROOT.
EDIT: I do not have a clang/ directory. %SDKROOT%\usr\lib\swift contains 5 directories: CFURLSessionInterface, CFXMLInterface, CoreFoudation, Shims, windows.
Note that the comment you screenshoted is using swift and not swiftc. The difference is material - you are invoking the immediate mode execution, which is not tested.
@compnerd, yes that's correct. I've tried a bunch of different things and didn't want to screenshot them all. I was just showing you the error that is being logged. I get the same results whether I use swift or swiftc.
Ah, okay, just wanted to make sure that you are using swiftc and are doing so from the "x64 Native Developer Command Prompt" (which is different from "Command Prompt").
@compnerd I tried again just now on the x64 using swiftc, just to be sure, but got the same errors. It seems that the build isn't finding or recognizing the stddef.h file.
That is actually very interesting! There is definitely an unexpected setup which means that the documentation might have resulted in the commands being incorrect for your setup. I don't know how to correct the documentation in light of that, but I think that getting your setup to work is relatively straight forward.
The thing to note is the search path that is being setup:
What this means is that you have a mismatch between the ucrt and the WinSDK installation. I'm not sure if Microsoft supports this configuration (you may need them to match), but in the case that it is supported, the result is that the files that you copied would be to the wrong directories. I cannot say without inspection of the system where the files ended up. However, copying the appropriate file (%SDKROOT%\usr\share\ucrt.modulemap to %ProgramFiles(x86)%\Windows Kits\10\include\10.0.18362.0\ucrt and %SDKROOT%\usr\share\winsdk.modulemap to %ProgramFiles(x86)%\Windows Kits\10\include\10.0.17763.0\um) should resolve the issue.
Hey @compnerd, I appreciate what you are doing for bringing swift on windows. I had the same errors as @briyo2289 and I have also followed the same steps, but I am still running into errors. I have copied the files into their appropriate location, but I am still running into errors. Attached is the screenshot of my error.
I believe that mixing versions isn't supported by Microsoft and I would recommend that you ensure that the versions match (you can either bump to the latest SDK at 19041 or get the older UCRT). Once you have run through the adjustments to the installation, just re-deploy the support files and it should work.
Thanks for reaching back @compnerd , I have installed the latest version of Windows SDK and all of the things ie (ucrt, shared, um ... etc) are all matching now. I am getting this error.
