[swift-evolution] #if os(Windows) and MSVC/Cygwin Compatibility

[Chris Lattner]

On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution <swift-evolution at 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/ <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 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.

I think it would be defensible to treat MSVC/MinGW as an os(Windows) but treat Cygwin as os(Cygwin).

How do other languages handle this?  What does dlang do, for example?

-Chris



> 
> (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.)
> 
> 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hello swift-evolution,
>> 
>> This is continued from PR #2351(https://github.com/apple/swift/pull/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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160503/ceeb20ff/attachment.html>