What are the minimal requirements for running Swift on Windows? Currently Swift requires Windows SDK and Visual Studio. These packages can take a large amount of disk space. Is it possible to pack only the files needed into a separate installer and distribute the installer instead? Or can we build with Mingw-W64 and remove these dependencies? AFAIK, LLVM itself can be built with Mingw-W64, what about Swift?
The Windows SDK an Visual Studio requirements are for developers, not for distribution. The need for it for development is for the windows SDK. Buried somewhere on Microsoft’s site is a standalone Windows SDK installer and that with the MSVCRT files is sufficient. Except you still need python, cmake, and LLDB requires ATL, so you’re basically better off with using Visual Studio to install all the dependencies at once. If you’re trying to build the compiler, that requires the build tools as well.
MinGW is just as large and installs a custom copy of most of these files, and is required for distribution. As a result the current Windows support is actually better!
I see. Thanks so much for your work on Windows!
BTW What is the status of SPM? Will it be distributed? Since it's not distributed by your builds I'm wondering how stable it is.
And REPL doesn't seem to work well. It gives a mysterious error saying that it can't construct a context. Is this expected?
I don't think that swift-package-manager is in a state where I would be comfortable with having that be part of the image.
The REPL issue however is not something that I am aware of. If you have the exact error, that would be nice. I have a few things that are currently pressing, but after that I can possibly look into the lldb situation again. I've managed to make a little headway with LLDB recently.
The error is
error: Could not construct an expression context for the REPL., the toolchain used is 20200228.2, but the problem doesn't happen in a fresh Release build.
Also I couldn't build libdispatch from a fresh build. LNK4217 and LNK4286 seem to be the reason, but disabling won't solve it. Log is here, return code is -1073740791(from swiftc.exe).
Ah, I think that is due to the layout differences - and its a bug in the REPL setup process.
Building libdispatch would be a challenge as the SDK contains a copy of libdispatch and so you will hit issues as modules would be redefined.
The return code indicates a crash, I think you would need to figure out where it is crashing and why.
I've build the toolchain again but with asserts enabled, now there's extra information: see here.
LLDB in a fresh build works, the flags are:
cmake -B "S:\b\toolchain" -G Ninja -S S:\toolchain\llvm -C S:\windows-swift\cmake\caches\Windows-x86_64.cmake -C S:\windows-swift\cmake\caches\org.compnerd.dt.cmake -DLLVM_ENABLE_ASSERTIONS=YES -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;cmark;swift;lldb;lld" -DLLVM_EXTERNAL_PROJECTS="cmark;swift" -DSWIFT_PATH_TO_LIBDISPATCH_SOURCE=S:\toolchain\swift-corelibs-libdispatch -DLLDB_ENABLE_PYTHON=NO -DSWIFT_WINDOWS_x86_64_ICU_UC_INCLUDE="S:/Library/icu-64/usr/include" -DSWIFT_WINDOWS_x86_64_ICU_UC="S:/Library/icu-64/usr/lib/icuuc64.lib" -DSWIFT_WINDOWS_x86_64_ICU_I18N_INCLUDE="S:/Library/icu-64/usr/include" -DSWIFT_WINDOWS_x86_64_ICU_I18N="S:/Library/icu-64/usr/lib/icuin64.lib" -DCMAKE_INSTALL_PREFIX="C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr" -DPYTHON_EXECUTABLE=C:\Python27\python.exe -DSWIFT_BUILD_DYNAMIC_STDLIB=YES -DSWIFT_BUILD_DYNAMIC_SDK_OVERLAY=YES -DLLVM_ENABLE_LIBXML2=NO -DLLVM_ENABLE_LIBEDIT=NO -DCMAKE_BUILD_TYPE=Release.
Also if you don't want to enable Python support in LLDB, you should probably use
Thats interesting. It seems that somehow a file handle is being closed twice? I've not seen that before. It's hard to say from that what file handle is being closed twice and why. This sounds like an issue in swiftc.
I've just found that the LLDB issue only happens when it is run out of the build tree, running it in build tree is fine. So the lldb.exe itself is fine.
Can you provide further details?
I don't remember the details off of the top of my head, but it comes down to the (Swift) compiler instance in lldb failing to load the swift standard library due to the paths its searching in missing an entry.