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

[Jordan Rose]

This is clever, but I’m not sure it’d get used anywhere else. In particular, I don’t think we want to demote the Apple OSs to be “Apple.OSX” and “Apple.iOS”, even though asking “am I on an Apple platform” is a reasonable question. Similarly, “POSIX?” is a reasonable query to ask of most OSs, but doesn’t fit into a hierarchy.

That said, sub-OSs of “Linux” would probably make plenty of sense…other than when a distro is forked. Hm.

Jordan


> On May 4, 2016, at 09:07, Michael Peternell <michael.peternell at gmx.at> wrote:
> 
> Hi,
> 
> just a quick question... would it maybe be feasible or practical to have "sub-OSes", like e.g. `#if os(Windows.MSVC)`, `#if os(Windows.Cygwin)` or `#if os(Windows.MinGW)`?
> 
> -Michael
> 
>> Am 03.05.2016 um 20:43 schrieb Jordan Rose via swift-evolution <swift-evolution at swift.org>:
>> 
>> 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.)
>> 
>> 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
>