I've added libdispatch with Swift support as well as SourceKit to the toolchain. As to the behavior with the modules, I would recommend filing a bug (sounds like a clang issue).
This is exciting to see. I don't know what your exact ambitions are, but if the goal is to eventually do Windows application development, there are a number of runtime customizations that could be done to make Swift a good platform citizen and interoperate with the platform. For instance, one could make class metadata and/or protocol witness tables COM compatible by sticking an
IUnknown implementation at the address point, so that Swift objects and existentials can be passed as COM objects. It should be possible to provide some amount of
IInspectable support based on Swift's metadata too.
That's an interesting idea @Joe_Groff! Certainly something to consider in the future, possibly under a flag, as it would be nice to have the same behaviour across all the platforms. I wonder if we could also make that work with XPCOM and XPC on the other targets.
I don't think we necessarily need the exact same object layouts on every target platform. For instance, the space taken up in class metadata for ObjC interop fields is wasted on non-Darwin platforms, and ObjC reification makes certain operations require one-time initialization that wouldn't otherwise, and all that code should just be disabled on non-Darwin platforms.
Apple has AppKit and ObjC runtime on Windows for iTunes (and Safari in the past).
If it is published, AppKit application can run on Windows.
I interested in this.
It's been years; I guess the chance of Apple's AppKit/ObjC on Windows becoming public is basically zero at this point.
On the mac, the basic system libraries are broadly split in to AppKit and Foundation (+ other stuff). Foundation is cross-platform, the source is already available, and @compnerd has done a lot of work porting it to Windows. AppKit, on the other hand, is generally not portable; it contains a lot of things specific to macOS, which might not even have equivalents on other platforms, or if they do they might look/behave differently. The thing that iTunes uses is probably only a subset of AppKit. Trying to squish one platform's concepts on to another is one of the reasons bringing UIKit to the mac has proven so controversial. Besides, it's not even clear what the future of AppKit is on the mac; it might all just be UIKit in the future. What I'm saying is: don't hold your breath. (just to make clear, because there are a lot of employees on these forums: I don't work at Apple).
Even though it's not an ideal solution, Microsoft did try and bring these libraries to Windows anyway as part of Objective-C for Windows, using the GNUStep runtime. We've talked about bridging with that runtime before, and I think the consensus was that the project maintainers aren't opposed to it, but also aren't interested in implementing/maintaining it themselves.
Also, to be clear, the OSS version of Foundation is written in Swift and it is intended to be source-compatible with the Darwin Objective-C based version while not requiring the Objective-C runtime.
Have been trying Dispatch and it seems to work great, thanks!
I don't know if it is the same error, but when I try to import
WinSDK after installing the
swiftc always throws a lot of import errors referencing that some type is unknown (eg.
error: "No Target Architecture" or
error: unknown type name 'PSLIST_HEADER'). On the other hand, the
MSVCRT module (and the underlying
visualc) works great.
That’s the same error, although I’m a little surprised you’re not seeing it with
MSVCRT; I also ran into it with importing
stdint.h. If you manually edit the WinSDK header files to change the
#pragma once guards to
#define pairs it should work.
39206 – [Modules TS] #pragma once leaks out of module files in a way that macros do not is the (preexisting) Clang bug that seems to reference the same issue.
Great to hear that libdispatch is working great for you!
Oh, right, thats under-documented, I'm sorry. I don't know where to put such a document. You need to specify the architecture that you are targeting when you compile unfortunately (
cl requires that too). Adding
-Xcc -D_AMD64_ or
-Xcc -D_X86_ should resolve the issue with
@jrose, what do you think of adding this in the frontend based on the triple?
That definitely seems reasonable to me. Clang predefines a whole bunch of macros like that on its own, so adding these few more (on Windows only) doesn't seem harmful. I suppose there's a chance someone wants to compile for Windows without using WinSDK, and might be using these names for something else, but that seems very unlikely.
The macros are in the reserved namespace, so, if they collide I'm not too worried.
Thanks for all the efforts in getting Swift to build & run on Windows @compnerd!
Would it be possible to include SwiftPM in your nightlies?
You're welcome :-). Unfortunately, I don't think that it is possible to include s-p-m just yet. I am still working on porting swift-corelibs-foundation to Windows. However, if I am mistaken and there is no dependency on Foundation for s-p-m, then assuming that the building s-p-m is as easy as libdispatch or Foundation (e.g. running CMake) then I can certainly include it.
Hi @compnerd, what do you think are the chances we're getting a CI here: GitHub - apple/swift-community-hosted-continuous-integration: Swift Community-Hosted Continuous Integration so that your great work on Windows doesn't break again?
SwiftPM does indeed require Foundation.
Unfortunately, I am using azure's services, not Jenkins for this, so I don't know how to integrate this into the community CI. If you have a way to integrate this into the community CI system, I would be thrilled to see that happen.
Well, I have no idea about administering azure's services nor Jenkins (since I am not a DevOp) but googling for azure services jenkins integration - Google Search brought up quite some hits, some even by Microsoft, for my naive eye the most relevant seemed to be Overview of Jenkins and Azure | Microsoft Learn . Maybe somebody else has more knowledge in this area. I am sorry that I can't really help here.
Yeah, devops is not what I normally work on either, so this is something foreign to me. I'm still busy making the compiler/runtime/standard library/support libraries work, and doing the CI stuff as best as I can. There is a bunch of work still left in the compiler/runtime that I'm still focused on, so if someone familiar with devops/azure takes a look at this, it would be helpful.
This is just awesome, thanks a lot for your hardwork; i wish i was skilled enough to be able to contribute
I can still try to help with porting the CI system to the community one, low level native development isn't my thing, but i will try !