> On May 3, 2016, at 12:29 PM, John McCall <[email protected]> wrote: > >> 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).
Yeah, in a previous thread the idea came up of an `imports(Module)` condition that would be true when Module was available for import. If we eventually grew standard POSIX and Win32 modules, that could cover those use cases. -Joe > 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] >> https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
