search

pwsacademy / swift-setup

Student-friendly setup instructions for platforms, editors, and IDEs that support Swift.
150 stars 11 forks source link

Add instructions for Windows. #2

Closed compnerd closed 3 years ago

svanimpe commented 3 years ago

Thanks @compnerd !

Can you ping me when the instructions/tools are stable enough for me to try out?

Also, what editors/IDEs will we be able to recommend for development on Windows? If the Windows build includes SourceKit-LSP, perhaps we can use Visual Studio Code with the SourceKit-LSP extension ? Do you know of any other student-friendly options?

compnerd commented 3 years ago

You're welcome. The instructions just need to wait for another snapshot to be built for them to be useable for command line usage. Eventually, VSCode would be the editor that students could use, but that requires a change in flight (otherwise completion is problematic if you use WinSDK).

compnerd commented 3 years ago

Okay, the current snapshot (10/22) I believe should be sufficiently new that we can just document the modern instructions, which also means that VSCode usage is nearly possible (it is possible as long as WinSDK is not imported - that will require the next snapshot).

svanimpe commented 3 years ago

@compnerd I hope to find some time later this week to try this out.

Some first glance questions:

Thanks!

compnerd commented 3 years ago

I’ve been trying to play with trying to remove it. The build tools are needed, but it’s a smaller install. I think that it’s best to keep the VS install for now, since otherwise you need to install python, git, build tools, and the MSVC redistributable. But that would avoid the editor.

The windows SDK is a hard requirement as foundation et al use it as does system. Most of the basic operations are not part of the C library.

The instructions need updating to indicate the 10/24 snapshot as the earliest to try.

svanimpe commented 3 years ago

@compnerd I was able to complete the installation and run swift --version.

Some questions that came up along the way:

Unfortunately, I wasn't able to run any Swift code:

I recall seeing some of these errors posted on the Swift Forums, so I will check the replies on those topics as well. In any case, I had hoped that the swift devenv command would have avoided any additional configuration steps. Ideally, I'd want students to be able to run the same commands on any platform.

compnerd commented 3 years ago

Installation:

Running:

If I can figure out how to copy visualc.modulemap, swift devenv will be sufficient to do all the setup, and that is what I would like to get to. The idea is that swift devenv --deploy post install would copy everything. swift devenv will spawn a shell that will have the environment setup and you can just launch VSCode or build in the terminal.

svanimpe commented 3 years ago

Thanks @compnerd. Let's continue with more feedback and questions 😅

compnerd commented 3 years ago

For swift however, it didn't make any difference; the issues remain the same.

Can you be a bit more precise about what the behaviour is that you see?

However, after swift build completes, it returns with an exit code of 1 and throws an error (NSCocoaErrorDomain Code=256 "(null)"). This doesn't seem to affect the build, but it does mean I can't use swift run.

swift run should work, I've definitely used it. Something is silently failing, could you build with -v and see what is returning EXIT_FAILURE?

The instructions on https://swift.org/getting-started/#installing-swift say to always use the x64 Native Tools for VS2019 Command Prompt to run the toolchain. Is this still required? The instructions in this PR only use Command Prompt.

Sadly, we still need to use the Native Tools command prompt. I need to test the last set of changes I made to devenv. If that now works as I want (swift devenv spawns a new shell), then either one works. Until that point, you need to use the "x64 Native Tools for VS2019 Command Prompt".

Do I need the x86 one specifically, or does the x64 one work too?

For the copy either works, ideally, I suppose we should just standardize on x64 as the toolchain is a 64-bit toolchain only.

I don't really get what swift devenv does yet.

It literally sets a couple of environment variables and gives you a shell with that setup. It just gives a simpler way to get the correct environment that you can get via the "x64 Native Tools for VS2019 Developer Command Prompt".

I can run swiftc and swift build from Command Prompt without running swift devenv first.

Have you tried compiling something more interesting than hello world? Once you start doing that, it will quickly fall apart because you need INCLUDE and LIB set properly.

I can also use the integrated terminal in Visual Studio Code (after setting it to cmd.exe instead of PowerShell) to run swift build, without running swift devenv first.

I suspect that you may have set extra environment variables that are not expected to be set all the time.

SourceKit-LSP seems to work fine in Visual Studio Code!

Yes, that is expected to work, though not perfectly yet. I know of a few places where it breaks down.

I can run executables with the CodeLLDB extension in Visual Studio Code. However, debugging doesn't work. The debugger seems to skip over breakpoints and never pauses. I also tried configuring the LLDB Library (see https://github.com/pwsacademy/swift-setup/blob/main/editors/vscode-linux/README.md) by setting it to the liblldb.lib file included with the toolchain, but that didn't work.

I don't know anything about CodeLLDB so I can't really say what is going on here.

I also noticed there's no .build/debug directory on Windows, which is unfortunate, as that made certain configuration steps easier.

I wonder if that is the error that you see. That sounds like a bug in SPM. Do you have developer mode enabled on Windows?

svanimpe commented 3 years ago

Can you be a bit more precise about what the behaviour is that you see?

Running swift -sdk %SDKROOT% prints an empty line and returns.

Running swift -sdk %SDKROOT% hello.swift prints <unknown>:0: error: could not load the swift standard library.

swift run should work, I've definitely used it. Something is silently failing, could you build with -v and see what is returning EXIT_FAILURE?

Running swift build -v on a Hello World package prints:

C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swiftc.exe -print-target-info
C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swiftc.exe -print-target-info
C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swiftc.exe -L C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\lib\swift\pm\4_2 -lPackageDescription -sdk C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk -libc MD -I C:\Library\Developer\Platforms\Windows.platform\Developer\Library\XCTest-development\usr\lib\swift\windows\x86_64 -L C:\Library\Developer\Platforms\Windows.platform\Developer\Library\XCTest-development\usr\lib\swift\windows -swift-version 5 -I C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\lib\swift\pm\4_2 -package-description-version 5.3.0 C:\Users\Steven\Documents\hello\Package.swift -o C:\Users\Steven\AppData\Local\Temp\TemporaryDirectory.RnutLD\hello-manifest.exe
C:\Users\Steven\AppData\Local\Temp\TemporaryDirectory.RnutLD\hello-manifest.exe -handle 2a8
C:\Users\Steven\Documents\hello: warning: Creating library C:\Users\Steven\AppData\Local\Temp\TemporaryDirectory.RnutLD\hello-manifest.lib and object C:\Users\Steven\AppData\Local\Temp\TemporaryDirectory.RnutLD\hello-manifest.exp
error: Error Domain=NSCocoaErrorDomain Code=256 "(null)"

It literally sets a couple of environment variables and gives you a shell with that setup. It just gives a simpler way to get the correct environment that you can get via the "x64 Native Tools for VS2019 Developer Command Prompt". Have you tried compiling something more interesting than hello world? Once you start doing that, it will quickly fall apart because you need INCLUDE and LIB set properly.

What are the correct values for these variables? If I run swift devenv in Command Prompt, it doesn't set these variables (meaning, I don't see them in the output of set). If I use the x64 VS Prompt, INCLUDE and LIB are already set and running swift devenv doesn't affect them. Their values are:

INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\winrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\cppwinrt

LIB=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\lib\x64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\ucrt\x64;C:\Program Files (x86)\Windows Kits\10\lib\10.0.19041.0\um\x64

I can run executables with the CodeLLDB extension in Visual Studio Code. However, debugging doesn't work. The debugger seems to skip over breakpoints and never pauses. I also tried configuring the LLDB Library (see https://github.com/pwsacademy/swift-setup/blob/main/editors/vscode-linux/README.md) by setting it to the liblldb.lib file included with the toolchain, but that didn't work.

I don't know anything about CodeLLDB so I can't really say what is going on here.

I'm trying to configure this extension as per https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#alternate-lldb-backends

I've tried pointing it to toolchain\usr\lib\liblldb.lib or to toolchain\usr\bin\liblldb.dll but neither work. The error is:

Error: "Could not load \"C:\\\\Library\\\\Developer\\\\Toolchains\\\\unknown-Asserts-development.xctoolchain\\\\usr\\\\bin\\\\liblldb.dll\" (err=0000007E)"
Error: The debugger exited without completing startup handshake.

On Linux, the correct path is toolchain\usr\lib\liblldb.so.

I wonder if that is the error that you see. That sounds like a bug in SPM. Do you have developer mode enabled on Windows?

No. Should I?

svanimpe commented 3 years ago

I did manage to start a REPL by doing the additional steps mentioned on https://swift.org/getting-started/#using-the-repl, but it crashed on my first command:

C:\Users\Steven\Documents\hello>path %ProgramFiles(x86)%\Microsoft Visual Studio\Shared\Python37_64;%PATH%

C:\Users\Steven\Documents\hello>swift repl -target x86_64-unknown-windows-msvc -sdk %SDKROOT% -I %SDKROOT%/usr/lib/swift -L SDKROOT%/usr/lib/swift/windows
Welcome to compnerd.org Swift version 5.3-dev (LLVM 56a74d3b9591abe, Swift 246fe46aa77b582).
Type :help for assistance.
1> print("Hello")
Assertion failed: false && "called into swift language runtime stub", file D:\a\1\s\llvm-project\lldb\source\Target\SwiftLanguageRuntime.cpp, line 301
 #0 0x00007ff78900d4a5 (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\lldb.exe+0x1d4a5)
 #1 0x00007ffcd11da3af (C:\Windows\System32\ucrtbase.dll+0x6a3af)
 #2 0x00007ffcd11db0a1 (C:\Windows\System32\ucrtbase.dll+0x6b0a1)
 #3 0x00007ffcd11dce0a (C:\Windows\System32\ucrtbase.dll+0x6ce0a)
 #4 0x00007ffcd11dcd05 (C:\Windows\System32\ucrtbase.dll+0x6cd05)
 #5 0x00007ffcd11dd03f (C:\Windows\System32\ucrtbase.dll+0x6d03f)
 #6 0x00007ffc953329ac PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x6729ac)
 #7 0x00007ffc99c0c2e4 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f4c2e4)
 #8 0x00007ffc99c11a56 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f51a56)
 #9 0x00007ffc99c0f226 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f4f226)
#10 0x00007ffc99c09b64 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f49b64)
#11 0x00007ffc951df197 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x51f197)
#12 0x00007ffc951ed627 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x52d627)
#13 0x00007ffc951b9cec PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4f9cec)
#14 0x00007ffc9516a069 PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4aa069)
#15 0x00007ffc95168c9e PyInit__lldb (C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll+0x4a8c9e)
#16 0x00007ffcd118fa95 (C:\Windows\System32\ucrtbase.dll+0x1fa95)
#17 0x00007ffcd19237e4 (C:\Windows\System32\KERNEL32.DLL+0x137e4)
#18 0x00007ffcd449cb61 (C:\Windows\SYSTEM32\ntdll.dll+0x6cb61)
compnerd commented 3 years ago

Ah, the "extra" stuff is getting Python into the path. That is part of why python is needed. The failure that you are seeing can be worked around (you need to copy the runtime into the toolchian). I haven't had time to look into why lldb is dropping Path in the REPL executable.

compnerd commented 3 years ago

What are the correct values for these variables? If I run swift devenv in Command Prompt, it doesn't set these variables (meaning, I don't see them in the output of set). If I use the x64 VS Prompt, INCLUDE and LIB are already set and running swift devenv doesn't affect them. Their values are:

There is no one correct answer to that, otherwise the tool would be pointless :) The correct value depends on your machine, time of installation, options selected during installation, method of installation, etc. Note that the release builds do not launch a shell, which makes it useless for setting the environment variable, you would need to build it from source. The values from the developer command prompt is the correct value for your machine at this time (it will also change over time).

I've tried pointing it to toolchain\usr\lib\liblldb.lib or to toolchain\usr\bin\liblldb.dll but neither work. The error is:

The libs are import libraries, they are used for linking only. The runtime component is the dll, which is only used at runtime. Im not sure what pointing CodeLLDB is supposed to accomplish. Again, someone who has time to understand CodeLLDB's code base is probably better suited to figuring that out. For now, I would recommend that you use the command line.

I wonder if that is the error that you see. That sounds like a bug in SPM. Do you have developer mode enabled on Windows? No. Should I?

Maybe? Creation of symbolic links is a privileged operation, however, setting into developer mode eases system restrictions (so, technically it is bad for a day-to-day user). If it is a symbolic link creation problem, that would potentially make the build type symlink show up. Also, now that I think about it - the error that you are mentioning might be due to this (that is your user does not have the rights to create the symbolic link and the error information is being lost during the bridging from NSError to Error (which was just recently fixed).

svanimpe commented 3 years ago

Creation of symbolic links is a privileged operation, however, setting into developer mode eases system restrictions (so, technically it is bad for a day-to-day user). If it is a symbolic link creation problem, that would potentially make the build type symlink show up. Also, now that I think about it - the error that you are mentioning might be due to this (that is your user does not have the rights to create the symbolic link and the error information is being lost during the bridging from NSError to Error (which was just recently fixed).

Switching to developer mode did indeed fix this. I now have the debug symlink an no longer get that error from swift build.

Note that the release builds do not launch a shell, which makes it useless for setting the environment variable, you would need to build it from source.

I'm now running the latest version of devenv, built from master, but it hasn't solved anything for me. I can see that it creates a new shell, however, that shell appears to be broken. Even a simple cd command doesn't work, it doesn't execute what I type, and the cursor can get stuck or move to other parts of the screen when I u se TAB or backspace 🤔

However, I can build both a hello-word package and swift-devenv just fine without running swift devenv first.

Let me know if there's anything else I can try.

If I find the time, I may also send some commits your way to update the instructions with what I've learned so far (so people watching this PR don't have to read this entire conversation).

compnerd commented 3 years ago

I'm now running the latest version of devenv, built from master, but it hasn't solved anything for me. I can see that it creates a new shell, however, that shell appears to be broken. Even a simple cd command doesn't work, it doesn't execute what I type, and the cursor can get stuck or move to other parts of the screen when I u se TAB or backspace 🤔

Interesting! Okay, that means that the stdout/stderr/stdin handles are in a weird state after the exec. That is rather unfortunate. There is no way to really do something like eval $(cmd) with the Windows command interpreter (and I haven't even thought about how to handle the differences for PowerShell).

However, I can build both a hello-word package and swift-devenv just fine without running swift devenv first.

Cool - are you using a developer command prompt or a plain command prompt? The former does not need devenv. The latter only needs it if you haven't tweaked your environment to set INCLUDE and LIB.

If I find the time, I may also send some commits your way to update the instructions with what I've learned so far (so people watching this PR don't have to read this entire conversation).

That would be amazing! I think that getting someone who isn't as familiar with all the pieces is actually very important to getting documentation that others can use. I feel like every attempt that I've made at documenting this stuff runs into confusion from others.

svanimpe commented 3 years ago

Cool - are you using a developer command prompt or a plain command prompt? The former does not need devenv. The latter only needs it if you haven't tweaked your environment to set INCLUDE and LIB.

I tried both.

It would be great if we could avoid the developer prompt all together. In VS Code, I rely on the built-in terminal a lot, so that too would have to support running swift commands. I can configure the built-in terminal to use cmd.exe or PowerShell, but not the VS developer prompts, as those don't appear to be executables, just scripts.

I also want to avoid the overhead of having to launch VS Code from a shell, but I assume that's a way for VS Code to inherit the LIB and INCLUDE variables from the shell? But once swift-devenv is working, can I run that from the VS Code built-in terminal as well to configure the environment variables? That would at least get me a good enough setup for my teaching needs.

That would be amazing! I think that getting someone who isn't as familiar with all the pieces is actually very important to getting documentation that others can use. I feel like every attempt that I've made at documenting this stuff runs into confusion from others.

Yeah writing good documentation (like teaching) is really hard. 😅 I'll see what I can come up with tomorrow!

compnerd commented 3 years ago

It would be great if we could avoid the developer prompt all together. In VS Code, I rely on the built-in terminal a lot, so that too would have to support running swift commands. I can configure the built-in terminal to use cmd.exe or PowerShell, but not the VS developer prompts, as those don't appear to be executables, just scripts.

Agreed, thats why I started devenv. Yes, the VS Developer Command prompt is just the standard command prompt with some scripts. The powershell vs cmd doesn't matter really - I routinely use SwiftPM in PowerShell. It is possible to have that work, its just a matter of configuring the environment variables.

svanimpe commented 3 years ago

@compnerd Do you have a small code example that I can use to test the environment? That is, code that requires INCLUDE and LIB to be set, and should not work without them? The programming challenges for my upcoming Swift fundamentals course compile just fine without these variables.

However, I did notice a few issues with console input and output:

I wrote a small snippet to illustrate these issues:

func readBool(question: String) -> Bool {
    var answer: String
    repeat {
        print("\(question) (y/n): ", terminator: "")
        answer = readLine()!
    } while answer != "y" && answer != "n"
    return answer == "y"
}

while readBool(question: "Do you feel lucky? 🤨") { }

In other news: I got the x64 VS Prompt working as the integrated terminal in Visual Studio Code :) The following options take care of that:

"terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
"terminal.integrated.shellArgs.windows": "/k \"C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Auxiliary\\Build\\vcvars64.bat\""

I assume/hope the location of that vcvars64.bat file is fixed?

This configuration could be helpful in running swift commands from the integrated terminal (in the absence of swift devenev), however, it does trip up the CodeLLDB extension. That no longer works now, because it seems to pass the build commands as arguments to that .bat file now. I'll have to look into that. I'm also wondering if the INCLUDE and LIB variables are only required when building, or also when running an executable? In the latter case, CodeLLDB won't need them anyway, and I'll have to find a way to set them only for the build task.

Finally, the version of Git that ships with Visual Studio seems to be outdated. I'm getting a lot of warnings about it, and even got an email from GitHub that this version will stop working after Nov. 13. That's strange, and will definitely confuse new users.

svanimpe commented 3 years ago

W.r.t launching LLDB from the command line, it also complains about not finding Python37.dll, so I need to execute this first:

path %ProgramFiles(x86)%\Microsoft Visual Studio\Shared\Python37_64;%PATH%

It's strange that VS doesn't put Python on the PATH when installing it. Is this something the Swift installer could take care of, so we can avoid this additional configuration step?

compnerd commented 3 years ago

Do you have a small code example that I can use to test the environment?

Without having thought too much about it, I believe that the following program should be sufficient:

import ucrt
public var alias = ucrt._read

Note that pre-existing module caches might interfere with this. The alias is so ensure that you fail twice, once at compile time, once at link time.

However, I did notice a few issues with console input and output:

There can be additional shell prompts mixed in with the output.

That might be due to the line terminator. I would recommend that you use the "one true" (if I don't make light of the myriad of differences between Windows and Unix I will go insane - and I keep forgetting how many there are; I don't mean to be flippant or insulting) line terminator: "\r\n" rather than the beloved Unix one of "\n".

Special characters (such as emoji or curly quotes) don't show up properly.

This is expected as you are printing in UTF-8. You should:

  1. ensure that the terminal font supports UTF-8 (Windows terminal's default works)
  2. Switch to UTF-8 encoding for the terminal via: 
    chcp 65001

Reading input with readLine also doesn't work properly, as what you type in, is not what the program receives. Sometimes, it appears as though the shell is parsing the input as a command.

That sounds really weird, I don't even have a guess as to what might be going on here.

I'll try to see if I can manage to find some time to play around with your example.

svanimpe commented 3 years ago

import ucrt public var alias = ucrt._read

Well, that also works for me, even in a regular Command Prompt, without INCLUDE and LIB set 😅. I've deleted my .build directory just in case, but it still works.

That might be due to the line terminator. I would recommend that you use the "\r\n" rather than the beloved Unix one of "\n".

But there is no explicit \n anywhere in that sample code? Could this be an issue in the Standard Library?

BTW: The weird I/O behavior I'm seeing from my apps is very similar (most likely identical) to what I'm getting from the new shell started by swift devenv. Maybe it's the same underlying issue?

chcp 65001

I looked into using the new Windows Terminal instead, but it turns out that's an even bigger mess 😕 It makes a big deal out of emojis in its trailer (https://www.youtube.com/watch?v=8gw0rXPMMPE) but that doesn't even work out of the box and requires even more additional installation steps. Even worse, the Windows Terminal just shows an error upon launch. It only works if you first launch a different terminal, so that's not exactly going to help me...

svanimpe commented 3 years ago

Hi @compnerd,

I've downloaded the new (29/10) snapshot to see if that fixes any of the issues above. Unfortunately, that doesn't appear to be the case.

However, I did notice something that may help you debug the I/O issue. I've noticed that this issue does not occur when I run an executable directly. That is:

swift build
.\.build\debug\my.exe

behaves correctly, but swift run does not and exhibits those I/O issues — the same ones I had with the shell generated by swift devenv. I hope this can help you pinpoint/fix the issue?

BTW: Let me know if I should file any of these issues on bugs.swift.org as well.

compnerd commented 3 years ago

I don't think that there's much that would've changed in the snapshot.

I'm unable to reproduce the issue locally. But the issue you say only shows up with swift run? That sounds like the spawning isn't setting up the stdin/stdout pipes correctly.

The emoji thing I think is that the string literal uses a literal emoji rather than the Unicode code point. The emoji gets converted to UTF-8, but doesn't convert to UTF-16 prior to printing.

I think both of these are useful to report to bugs.swift.org for tracking purposes.

compnerd commented 3 years ago

FWIW: this is what Im seeing on Windows: image

The difference is that the console output needs to be put into UTF-8 mode, which perhaps we should do in the runtime.

func readBool(question: String) -> Bool {
    var answer: String
    repeat {
        print("\(question) (y/n): ", terminator: "")
        answer = readLine()!
    } while answer != "y" && answer != "n"
    return answer == "y"
}

import WinSDK
_ = SetConsoleOutputCP(UINT(CP_UTF8))
while readBool(question: "Do you feel lucky? 🤨") { }
svanimpe commented 3 years ago

Thanks @compnerd

I've reported the following issues:

I think I have enough information now to start writing some instructions. However, I'm still looking for an example that does not compile without INCLUDE and LIB, so I can figure out how I can set up VS Code correctly.

compnerd commented 3 years ago

I believe that the initial WinSDK module compile and any subsequent use of C code should provide that case. Swift/Win32 or swift-nio are good candidate packages that should demonstrate the need for the environment variables.

svanimpe commented 3 years ago

Well, I can compile code that uses WinSDK to set the code page just fine from a PowerShell without INCLUDE and LIB configured 😅 Same goes for the Win32 UICatalog example.

W.r.t. NIO, I'm not sure how I can test that. Which target should I try building? I tried building the NIO target but that failed, even in the x64 VS Prompt.

Basically, I'm just trying to figure out what I should put in the installation instructions w.r.t. INCLUDE and LIB. That is: users can get pretty far with just Command Prompt or PowerShell, so we need to be clear about when they need to use the VS Prompt instead, or, in the future, use swift-devenv. That's not something I fully understand at the moment.

svanimpe commented 3 years ago

@compnerd I've sent a PR over to your fork with an attempt at user-friendly instructions.

svanimpe commented 3 years ago

@compnerd I'm merging this so others can start trying out the instructions.

Can you ping me when something changes in Windows land and I should update the instructions?

svanimpe commented 3 years ago

Also, any retweets for https://twitter.com/pwsacademy/status/1324660121084006401 are welcome, so we can actually get these instructions to people who want to test them 😅