> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > We’ve had this kind of thing come up before, too, with the > Linux/FreeBSD/Android group vs. the OSX/iOS/watchOS/tvOS group, or with > 32-bit architectures vs. 64-bit architectures. Erica Sadun wrote up quite a > few of the choices here: > http://thread.gmane.org/gmane.comp.lang.swift.evolution/12161/ > > …none of which quite match the MSVC vs. Cygwin distinction. (And where does > MinGW fit in?) > > (I think there was another thread with even more possible platform > conditions, but I can’t find it.) > > One thing that I’d like to keep is that os(…) (like arch(…)) is (a) > non-overlapping and (b) covers everything, i.e. there should never be a > platform Swift supports for which no os(…) predicate is true. That doesn’t > have to be the case for other, new predicates, though. > > I think one of the big questions (already identified in this thread) is “how > often does the same code apply for both Cygwin and Windows?” If the answer is > “pretty much never” or even “rarely", then treating them as separate “OSs” > seems fine—in the rare case someone can use “os(Windows) || os(Cygwin)”. > However, if the answer is “most of the time” (leaving the standard library > out of it, since that’s not representative of average user code), then it > feels like the common “os(Windows)” predicate makes more sense, and we should > come up with something else to distinguish them. > > (Again, “where does MinGW fit in?” might help clarify this direction.)
Windows doesn't specify a standard C or C++ ABI, and until recently didn't even provide a common C runtime in the OS, so Cygwin/Mingw and MSVC are essentially completely different C environments. Cygwin and Mingw are more similar to each other ABI-wise, both being derived from GCC, but differ widely in the C APIs they provide, since Cygwin aims to provide a more complete POSIX-like environment, whereas Mingw only provides an implementation the standard C libraries. Where there's overlap between Cygwin, Mingw, and MSVC is in the Win32 system APIs, which do have de-facto standard ABIs. To me, this suggests considering them to be different "os" environments, but grouping them together under some new higher-level condition. Much like you could group Linux, BSD, and MacOS in a "POSIX" umbrella, Cygwin, Mingw, and MSVC could be grouped under a "Win32" umbrella (though Cygwin straddles the line somewhat). -Joe > We’re also free to rename things in this discussion. If it turns out there’s > a better word than “os”, we can switch to it. > > Jordan > > > >> On May 2, 2016, at 22:00, Sangjin Han via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello swift-evolution, >> >> This is continued from PR #2351(https://github.com/apple/swift/pull/2351). >> >> Here is the brief history. (To avoid confusion, I used MSVC refer to >> *-*-windows-msvc and Cygwin refer to *-*-windows-cygnus in LLVM.) >> >> I needed the #if method to distinct MSVC from Cygwin, for mapping the Int to >> CLongLong not CLong on MSVC. >> In PR #2351, I simply added 'os(Cygwin)' and restrict 'os(Windows)' to >> *-*-windows-msvc from *-*-windows-*, this solved my problem. >> >> Jake(@jakepetroules) pointed out that Cygwin is not an OS and it will never >> fixed to avoid breaking user applications. >> There is more participants and opinions, briefly, >> - introduce another new one such as 'env(cygnus)' or 'triple(Cygwin)' >> - the usability of the common condition 'os(Windows)' for *-*-windows-* >> - fundamentally, what do we gain from asking which os() is in use? >> - 'env()' is too vague >> - what the right questions? >> >> Forgive me the poor quotations of valuable opinions. >> >> >> I hope we find out the solution or method everybody satisfied. >> >> >> -Han Sangjin >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
