#if os(Windows) and MSVC/Cygwin Compatibility

tinysun212 · 2016-05-03T05:00:28.000Z

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

Michael_Buckley · 2016-05-03T16:07:46.000Z

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@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@swift.org> wrote:
> Hello swift-evolution,
>
> This is continued from PR #2351([Compiler] Cygwin is identified by os(Cygwin) instead of os(Windows) by tinysun212 · Pull Request #2351 · apple/swift · GitHub
).
>
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

owensd · 2016-05-03T16:11:54.000Z

Historically, that's been true. However, I wonder if the new Linux subsystem work for Windows changes this.

learn.microsoft.com

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@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@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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Joe_Groff · 2016-05-03T16:14:49.000Z

Why is there a need to support Cygwin/MingW and their variants as a
build target for Windows? MSVC is practically free these days.

Cygwin at least is still valuable for providing a more POSIX-like environment for portability, without the Win32 interop barriers that the old NT POSIX subsystem (and presumably the new Linux syscall layer thing) have. At the language level, MSVC's C and C++ frontends are still fairly idiosyncratic compared to GCC or Clang, so I know a number of people who prefer Mingw on those grounds too.

-Joe

···

On May 3, 2016, at 2:44 AM, hitstergtd+swiftevo--- via swift-evolution <swift-evolution@swift.org> wrote:

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Michael_Buckley · 2016-05-03T16:22:48.000Z

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@owensd.io> wrote:

Historically, that's been true. However, I wonder if the new Linux
subsystem work for Windows changes this.

Windows Subsystem for Linux Overview | Microsoft Learn

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@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@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@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

John_McCall · 2016-05-03T16:35:54.000Z

I want to stop this thread of the conversation here. This is not a general technology discussion forum; it's not our place to second-guess whether Cygwin is useful. The Swift project's primary criterion for accepting a port is whether there are contributors willing to maintain it. That's not the only criterion — I could certainly imagine ports that would be too burdensome on the compiler to be worth trying to support, like a platform with a 12-bit byte — but I have seen no argument that the Cygwin port comes close to crossing that line.

John.

···

On May 3, 2016, at 9:22 AM, Michael Buckley via swift-evolution <swift-evolution@swift.org> wrote:
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.

Hitstergtd_Swiftevo · 2016-05-03T09:44:47.000Z

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

jrose · 2016-05-03T18:43:47.000Z

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Joe_Groff · 2016-05-03T19:15:32.000Z

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).

-Joe

···

On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

John_McCall · 2016-05-03T19:29:50.000Z

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.

···

On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

jberry · 2016-05-03T19:30:09.000Z

...

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.

So if os(…) should be exclusive, then os(Windows) should presumably cover Windows, Cygwin, and Mingw.

But it seems like there’s an argument for some new predicate that is not exclusive… see below...

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).

Right, so maybe there’s an api(…) predicate, that is not exclusive, that tells what api famiilies are supported.

MSVC would return true for api(Win32)
Cygwin would indicate api(Win32) and api(POSIX) maybe
Mingw: api(Win32) (don’t know what else as I don’t know much about Mingw)

Maybe this is also a way to indicate flavors of linux support, i.e., a linux API system might indicate api(linux) and api(posix), while a MacOSX system might indicate api(posix), api(darwin), api(macosx), api(BSD), (or whatever).

James

···

On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

-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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Joe_Groff · 2016-05-03T20:50:49.000Z

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).

Yeah, in a previous thread the idea came up of an `imports(Module)` condition that would be true when Module was available for import. If we eventually grew standard POSIX and Win32 modules, that could cover those use cases.

-Joe

···

On May 3, 2016, at 12:29 PM, John McCall <rjmccall@apple.com> wrote:

On May 3, 2016, at 12:15 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris_Lattner · 2016-05-04T04:22:29.000Z

+1.

-Chris

···

On May 3, 2016, at 9:35 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On May 3, 2016, at 9:22 AM, Michael Buckley via swift-evolution <swift-evolution@swift.org> wrote:
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.

I want to stop this thread of the conversation here. This is not a general technology discussion forum; it's not our place to second-guess whether Cygwin is useful. The Swift project's primary criterion for accepting a port is whether there are contributors willing to maintain it.

Chris_Lattner · 2016-05-04T04:27:20.000Z

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 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

···

On May 3, 2016, at 11:43 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

(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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Michael_Peternell · 2016-05-04T16:07:09.000Z

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Joe_Groff · 2016-05-04T04:39:33.000Z

Part of the problem is that MSVC and Mingw *don't* share a C ABI or runtime. Only 'stdcall' and COM stuff from the Win32 system APIs is portable between them at the binary level.

-Joe

···

On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

MSVC and MinGW (again, AFAIK) use the same C ABI, and thus could be treated as the same target.

jrose · 2016-05-04T16:15:18.000Z

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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris_Lattner · 2016-05-04T04:40:50.000Z

I thought that MinGW worked with the system libc?

-Chris

···

On May 3, 2016, at 9:39 PM, Joe Groff <jgroff@apple.com> wrote:

On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

MSVC and MinGW (again, AFAIK) use the same C ABI, and thus could be treated as the same target.

Part of the problem is that MSVC and Mingw *don't* share a C ABI or runtime. Only 'stdcall' and COM stuff from the Win32 system APIs is portable between them at the binary level.

Joe_Groff · 2016-05-04T04:43:07.000Z

There's no such thing on Windows (at least, until Windows 10, which introduced yet another "universal" C runtime). Older versions of mingw used to link against MSVCRT.DLL, which was an unsupported vintage C runtime intended for SPI use only, but now use their own glibc-derived C library.

-Joe

···

On May 3, 2016, at 9:40 PM, Chris Lattner <clattner@apple.com> wrote:

On May 3, 2016, at 9:39 PM, Joe Groff <jgroff@apple.com> wrote:

On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

MSVC and MinGW (again, AFAIK) use the same C ABI, and thus could be treated as the same target.

Part of the problem is that MSVC and Mingw *don't* share a C ABI or runtime. Only 'stdcall' and COM stuff from the Win32 system APIs is portable between them at the binary level.

I thought that MinGW worked with the system libc?

Hitstergtd_Swiftevo · 2016-05-04T05:31:23.000Z

Dear Joe, Chris, Swift Community,

Here is my quick fire view.

What about adding a builtin directive called environ(...) for holding
OS-specific environmental differences. So in the case of Windows, we would
potentially have environ(msvc), environ(cygwin), environ(mingw),
environ(nano) etc. Thus, having environment as a separate builtin directive
allows Swift and its users to cleanly handle significant divergence on a
single operating system by way of combinations.

Similarly, an environ(posix) could also be added in the same spirit, in the
future, if required, if a POSIX specific environment is required.

The good thing about the above is that it can be intuitively used to build
combinations such as the following and has good readability:

if os(Windows)
// ... common stuff to Windows in general
if environ(Cygwin) and arch(x86_64)
// ... specific stuff of Cygwin on 64-bit arch
#elseif environ(msvc)
// ... stuff specific to MSVC generally
#endif

#else
// ... Non Windows stuff.
#endif

Chris, for your reference, the following is how D does it:
Conditional Compilation - D Programming Language. TL;DR - precursory
look indicates that they cobble everything into version() with predefined
identifiers.

I have specifically left out any comments on OS versions such as Vista,
Windows 7 etc., as I am not sure on how it should be handled, either
presently or as a proposal. As for Cygwin and MinGW, I am not sure if it
should be called cygwin32 and mingw32 with their 64-bit analogues,
respectively, but AFAICS, not suffixing with 32 and 64 seems much cleaner.

Thanks.

···

On Wed, 4 May 2016 at 05:41, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

> On May 3, 2016, at 9:39 PM, Joe Groff <jgroff@apple.com> wrote:
>
>
>> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> MSVC and MinGW (again, AFAIK) use the same C ABI, and thus could be
treated as the same target.
>>
> Part of the problem is that MSVC and Mingw *don't* share a C ABI or
runtime. Only 'stdcall' and COM stuff from the Win32 system APIs is
portable between them at the binary level.

I thought that MinGW worked with the system libc?

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution