Dear Swift Community, I think that the `imports(Module)` condition is more reasonable than 'os()' in writing module applications. But we need another condition, as this case was origin to distinct LLP64 from LP64 for the library.
I hope we get any condition which can equivalent or covering 'triple()' for the following code. (in core/CTypes.swift) /// The C 'long' type. +#if triple(x86_64-*-windows-msvc) || triple(x86_64-*-windows-gnu) +public typealias CLong = Int32 +#else public typealias CLong = Int +#endif /// The C 'long long' type. +#if triple(x86_64-*-windows-msvc) || triple(x86_64-*-windows-gnu) +public typealias CLongLong = Int +#else public typealias CLongLong = Int64 +#endif Moreover, it will be required to distinct MinGW(*-*-windows-gnu) from *-*-windows-msvc, because MinGW and Cygwin can support Float80 differently from MSVC. We already have the 'arch()' for the first part of the triple. How about 'environ(windows-msvc)', 'environ(windows-cygnus)' for portable module writers to cover full triple? - Han Sangjin 2016-05-04 14:31 GMT+09:00 hitstergtd+swiftevo--- via swift-evolution < [email protected]>: > 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: > https://dlang.org/spec/version.html#predefined-versions. 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 < > [email protected]> wrote: > >> >> > On May 3, 2016, at 9:39 PM, Joe Groff <[email protected]> wrote: >> > >> > >> >> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution < >> [email protected]> 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 >> [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
