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