> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution > <[email protected]> wrote: >> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution >> <[email protected]> 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).
Should we have a condition that checks for these broad API sets, then? API(POSIX), API(Windows), etc.? Possible direction for growth: checking for the availability of a specific library, like #if hasLibrary(libjpeg). John. > > -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 >>> <[email protected]> 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 >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
