> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > >> On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org> wrote:
... >> >> 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. So if os(…) should be exclusive, then os(Windows) should presumably cover Windows, Cygwin, and Mingw. But it seems like there’s an argument for some new predicate that is not exclusive… see below... >> >> 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). Right, so maybe there’s an api(…) predicate, that is not exclusive, that tells what api famiilies are supported. MSVC would return true for api(Win32) Cygwin would indicate api(Win32) and api(POSIX) maybe Mingw: api(Win32) (don’t know what else as I don’t know much about Mingw) Maybe this is also a way to indicate flavors of linux support, i.e., a linux API system might indicate api(linux) and api(posix), while a MacOSX system might indicate api(posix), api(darwin), api(macosx), api(BSD), (or whatever). James > > -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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
