I made a PR https://github.com/apple/swift/pull/2351 introducing os(Cygwin).
2016-04-27 5:54 GMT+09:00 John McCall <[email protected]>: > > On Apr 26, 2016, at 1:39 PM, Joe Groff <[email protected]> wrote: > >> On Apr 26, 2016, at 1:24 PM, John McCall via swift-evolution < > [email protected]> wrote: > >> > >>> On Apr 26, 2016, at 1:03 PM, Sangjin Han <[email protected]> > wrote: > >>> The problem can be solved by modifying that code. Thanks you. I > thought that code will affect only to the CLong type not Int. > >> > >> It changes what 'long' gets imported as. If there's a Windows API > defined using 'long' (rather than some more meaningful typedef like > 'size_t'), it's important for it to be imported as Int32 rather than Int, > since 'long' is always 32 bits under MSVC. > >> > >>> But I meet another problem to fix it. I couldn't find the conditional > method to distinct x86_64-*-windows-msvc with x86_64-*-windows-cygnus in > Swift source. > >>> > >>> "#if os(Windows)" can not distinct MSVC from Cygwin. > >>> > >>> Should I add new condition 'env()' for the environment? > >> > >> That is an excellent question. > >> > >> My understanding / memory is that, as far as their programming > interfaces goes, Cygwin and MSVC are very, very different environments. > Maybe it's useful to have a condition that's true for both environments — > although I'm not sure why it would — but I don't think it deserves to be as > prominent as os(Windows). So my gut reaction is that, rather than adding a > #env, we ought to just reserve os(Windows) for MSVC compatibility and make > a new os(Cygwin) for Cygwin. > >> > >> This needs to be raised on swift-evolution, though. CC'ing that list. > > > > It's an interesting question. Mingw, Cygwin, and MSVC definitely vary > greatly in ABI and C language level behavior, but the underlying Win32 > system libraries remain the same. I think it makes sense to consider them > different os(...) environments, but it would also make sense IMO to have a > broader platform check for Win32. > > If, after import and however much magic, they both end up exposing a > similarly-typed set of system APIs, I agree that it makes sense to have a > condition that says "yes, the target has those APIs". It certainly seems > like a worthwhile goal for Swift to present them with the same imported > types. > > John.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
