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

[John McCall]

> On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 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/
>> 
>> …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 <swift-evolution at 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 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/9e60c3f7/attachment.html>