> On May 3, 2016, at 2:44 AM, hitstergtd+swiftevo--- via swift-evolution > <[email protected]> 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.
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 > 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 > <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
