But that is for building the toolchain, not a Swift program, right? No problem with VS as a prerequisite for building the toolchain.
It's not just the toolchain, but rather, the standard library. These are built as a bunch of .dll and .lib files, and the tooling you use here matters. Is it possible to use .lib files created by VS with other tools? Maybe, but it wouldn't be a pretty process.
I am going a bit about-ish here, because, as I've said, there's no decent documentation regarding the contents of %LOCALAPPDATA%\Programs\Swift\Platforms\<version>\Windows.platform\Developer\SDKs\Windows.sdk. If there was, it might have been clearer as to what needs to be changed in order to remove dependency on VS.
You would probably also need changes to SwiftPM with regards to the default parameters passed to swiftc, e.g. libraries and include folders, to not use ones obtained from VS. Although this can be circumvented by using custom build scripts instead of SPM.
That isn't the case. Take a look at GitHub - thebrowsercompany/swift-build: Swift toolchain builds by The Browser Company. These toolchains have 7 SDKs (3 for Windows, 4 for Android). They have a single variant of the SDK for each of the platform - dynamic release dynamic (dynamically linked runtime built in release and dynamically linking to system libraries).
Oh so you are not interested in the Windows toolchain! You want a MinGW toolchain. There was some work that was done to support that but was never completed.
There is also a cygwin port that does exist but has likely suffered some bit rot due to under maintenance.
The Windows port has always been about targeting MSVC with the Microsoft ABI and the Microsoft libraries. The MinGW and Cygwin ports are possible and did function at one point and should be possible to revive, but as you said - it would be an undertaking.
It really doesn't contain much. It contains:
- The Swift runtime - the libraries under stdlib
- swift-corelibs-libdispatch
- swift-corelibs-foundation / swift-foundation
- swift-corelibs-xctest / swift-testing
- A few auxiliary fixes (see 1 for the source)
Again building that is documented in build.ps1. But this will not go MSVC free, it can try to minimise the public dependency on ucrt, but will always require MSVC. If you want a truly MSVC free build, then reviving the MinGW port is the right approach.
I suppose you mean this part and this part. It's a bit hard to parse a 4000 line workflow script.
The OP requested "Not VS" (See the title of this thread). This significantly limits the options. Last I checked, clang doesn't have a built-in stdlib. I'm not sure if Windows SDK does, and it likely depends on VS anyway. This makes the remaining options be MinGW, cygwin or roll-your-own (Technically doable if you hand-write .def files for Kernel32.dll, but a TON of work).
I mean, I suppose you can interpret "Not VS" as "MSVC that is not VS", but that reads like an oxymoron...
2 Likes
I don't think it is an oxymoron. The Windows SDK is available as a standalone package. Python is available as a standalone package. The only piece that you need is the headers and import libraries for the MSVC runtime which is a subset of the MSVC Build Tools. If that were separated and made available as a standalone package, that would allow you to build without Visual Studio.
The piece that @sspringer raised again as:
would be satisfied by that - the terms for WinSDK and those are not the same as the rest of VS and would not require the the VS license or trying to get into the commercial license programs.
2 Likes
Would it instead be possible to remove the dependency on the MSVC runtime, while keeping everything else?
Yes, this would be nice, the least of all because it makes the installation process simpler. This is effectively what @tristanlabelle's request enables - by requesting that they make the C/C++ headers and import libraries available standalone, it would allow this. BTW, this is also required on Linux and any other platform. So, this is not a Windows specific requirement. It is just that the headers and import libraries are not available as a separate package.
That is what we have already done 
The recommendation from Microsoft is to do dynamic linking, and that matches the recommendation as the platform owner.
Yes! However, the costs are absurd. We need to reduce the build times to something reasonable. Lets assume that a single host takes ~50 hours to build. We need a ~20x speed up here. These builds are on a 24c, 64G RAM machine backed by nVME. I think that we would need a 128c machine with 512G or 1T RAM. Additionally, to keep up with demand, we would likely need a fleet of these machines. This is obviously going to be pretty expensive, and I think that the resources are better used elsewhere.
Building the SDK and toolchain are separate. While the build-script method ties them together, if you look at build.ps1, for Windows, we split them off into separate stages.
No, that is not possible. The MSVC runtime is part of the dependency set and cannot be removed. It will always be a dependency for the Windows port. If you want to remove that, you would need to look at the non-Windows ports like Cygwin. The MinGW port simply does a rebuild of the MSVC runtime and ships that, so that still technically depends on it.
I actually had to double check programs I know for a fact were built with MinGW, and found a dependency on MSVCRT. At the same time, MinGW is able to build programs even when VS is not installed (even on Linux, where it can't be installed). So, in theory, Swift could draw the MSVCRT headers and library files from a local MinGW installation instead of from VS, no?
I judge using MinGW (or Cygwin) as much worse than demanding a VS installation, on legal issues as well as support. Many companies have banned MinGW/Cygwin long ago. And taking files from somewhere else that otherwise are not legal to use independently does not seem to be a solution (or am I seeing it wrong?).
BTW just to be sure: The parts of VS that are needed are not “free to use” by Microsoft’s definition? (I posted the same link already above.)
No, it cannot. The headers that MinGW uses are re-created and do not necessarily match exactly with what the next release of the Windows SDK contains (even if they are identical to the current release, which I'm not entirely certain about).
The Swift toolchain is a complete toolchain - it doesn't depend on the MSVC tools. It does depend on the C library's headers, just like you depend on the C library headers on Linux and macOS.
We need a subset of that - only the CRT, we do not use MFC, AMP, or OpenMP. That dependency would remain there even if static linking is used - it would just be that it would be statically linked into the library and the dependency would only be pulled in if you are pulling in any pieces of the system yourself (aka, if you want to use anything on Windows, e.g. puts). Even if you are abstracting through Foundation, you would still be dependent on these libraries as it will itself use them.