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

[Michael Buckley]

I may be fundamentally misunderstanding the Windows Subsystem for Linux,
but I believe it just provides binary compatibility for Linux x86_64
command-line tools, but doesn't quite implement enough of the Linux
syscalls to run a Linux window manager in order to run GUI programs. So
it's certainly something you could compile your server code for if you
wanted to host on a Windows server, but it's not something you could use to
distribute client software.

On Tue, May 3, 2016 at 9:11 AM, David Owens II <david at owensd.io> wrote:

> Historically, that's been true. However, I wonder if the new Linux
> subsystem work for Windows changes this.
>
>
> https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
>
> And further, will we need a check for this on Windows?
>
> -David
>
> Sent from my iPhone
>
> On May 3, 2016, at 9:07 AM, Michael Buckley via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I wouldn't personally use a Cygwin or MinGW target these days, but I can
> see why a Cygwin target would be useful in a Swift context. I suspect most
> Swift code is either going to be written for iOS/Mac, or Linux server code,
> including third-party libraries. Lots of Swift code will probably have some
> POSIX calls that wouldn't otherwise be available on Windows.
>
> On Tue, May 3, 2016 at 2:44 AM, hitstergtd+swiftevo--- via swift-evolution
> <swift-evolution at swift.org> wrote:
>
>> Why is there a need to support Cygwin/MingW and their variants as a
>> build target for Windows? MSVC is practically free these days.
>>
>> Doesn't supporting multiple different ABI targets on Windows just
>> complicate matters unnecessarily? Isn't MSVC enough as a build target?
>>
>> I am not dejecting; rather, just wondering the actual need.
>>
>> On 3 May 2016 at 06: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
> 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/04becadb/attachment.html>