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

[Sangjin Han]

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 <
swift-evolution at swift.org>:

> 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 <
> swift-evolution at swift.org> wrote:
>
>>
>> > On May 3, 2016, at 9:39 PM, Joe Groff <jgroff at apple.com> wrote:
>> >
>> >
>> >> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution <
>> swift-evolution at 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 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/20160504/7dca3389/attachment.html>