<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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: <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/12161/" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/12161/</a></div><div class=""><br class=""></div><div class="">…none of which quite match the MSVC vs. Cygwin distinction. (And where does MinGW fit in?)</div></div></div></blockquote><div><br class=""></div><div>I am not a windows guru (and haven’t used it for over a decade) but my understanding is that Cygwin is a different target (as in different target triple, different ABI, different environment) from MSVC and MinGW. If that is the case, it should be its own “arch” or “os”. MSVC and MinGW (again, AFAIK) use the same C ABI, and thus could be treated as the same target.</div><div><br class=""></div><div>I think it would be defensible to treat MSVC/MinGW as an os(Windows) but treat Cygwin as os(Cygwin).</div><div><br class=""></div><div>How do other languages handle this? What does dlang do, for example?</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">(I think there was another thread with even more possible platform conditions, but I can’t find it.)</div><div class=""><br class=""></div><div class="">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 <i class="">no</i> os(…) predicate is true. That doesn’t have to be the case for other, new predicates, though.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">(Again, “where does MinGW fit in?” might help clarify this direction.)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 2, 2016, at 22:00, Sangjin Han via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><span class="" style="font-size:14px">Hello</span><span style="font-size:14px" class=""> swift-evolution,</span><br class=""></div><div class=""><br class=""></div><div class="">This is continued from PR #2351(<a href="https://github.com/apple/swift/pull/2351" class="">https://github.com/apple/swift/pull/2351</a>).</div><div class=""><br class=""></div><div class="">Here is the brief history. (To avoid confusion, I used MSVC refer to *-*-windows-msvc and Cygwin refer to *-*-windows-cygnus in LLVM.)</div><div class=""><br class=""></div><div class="">I needed the #if method to distinct MSVC from Cygwin, for mapping the Int to CLongLong not CLong on MSVC.</div><div class="">In PR #2351, I simply added 'os(Cygwin)' and restrict 'os(Windows)' to *-*-windows-msvc from *-*-windows-*, this solved my problem.</div><div class=""><br class=""></div><div class="">Jake(@jakepetroules) pointed out that Cygwin is not an OS and it will never fixed to avoid breaking user applications.</div><div class="">There is more participants and opinions, briefly,</div><div class="">- introduce another new one such as 'env(cygnus)' or 'triple(Cygwin)'</div><div class="">- the usability of the common condition 'os(Windows)' for *-*-windows-*</div><div class="">- fundamentally, what do we gain from asking which os() is in use?</div><div class="">- 'env()' is too vague</div><div class="">- what the right questions?</div><div class=""><br class=""></div><div class="">Forgive me the poor quotations of valuable opinions.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I hope we find out the solution or method everybody satisfied.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-Han Sangjin</div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>