<div dir="ltr"><div>Dear Swift Community,</div><div><br></div><div>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.</div><div><br></div><div>I hope we get any condition which can equivalent or covering 'triple()' for the following code.</div><div><br></div><div> (in core/CTypes.swift)</div><div> </div><div> /// The C 'long' type.</div><div> +#if triple(x86_64-*-windows-msvc) || triple(x86_64-*-windows-gnu)</div><div> +public typealias CLong = Int32</div><div> +#else</div><div> public typealias CLong = Int</div><div> +#endif</div><div> <span class="" style="white-space:pre"> </span> </div><div> /// The C 'long long' type.</div><div> +#if triple(x86_64-*-windows-msvc) || triple(x86_64-*-windows-gnu)</div><div> +public typealias CLongLong = Int</div><div> +#else</div><div> public typealias CLongLong = Int64</div><div> +#endif</div><div> </div><div>Moreover, it will be required to distinct MinGW(*-*-windows-gnu) from *-*-windows-msvc, because MinGW and Cygwin can support Float80 differently from MSVC.</div><div><br></div><div>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?</div><div><br></div><div><br></div><div>- Han Sangjin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-04 14:31 GMT+09:00 hitstergtd+swiftevo--- via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">Dear Joe, Chris, Swift Community,<br><br>Here is my quick fire view.<br><br>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.<br><br>Similarly, an environ(posix) could also be added in the same spirit, in the future, if required, if a POSIX specific environment is required.<br><br>The good thing about the above is that it can be intuitively used to build combinations such as the following and has good readability:<br><br>#if os(Windows)<br> // ... common stuff to Windows in general<br> #if environ(Cygwin) and arch(x86_64)<br> // ... specific stuff of Cygwin on 64-bit arch<br> #elseif environ(msvc)<br> // ... stuff specific to MSVC generally<br> #endif<br><br>#else<br>// ... Non Windows stuff.<br>#endif<br><br>Chris, for your reference, the following is how D does it: <a href="https://dlang.org/spec/version.html#predefined-versions" target="_blank">https://dlang.org/spec/version.html#predefined-versions</a>. TL;DR - precursory look indicates that they cobble everything into version() with predefined identifiers.<br><br>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.<br><br>Thanks.</div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, 4 May 2016 at 05:41, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On May 3, 2016, at 9:39 PM, Joe Groff <<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>> wrote:<br>
><br>
><br>
>> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> MSVC and MinGW (again, AFAIK) use the same C ABI, and thus could be treated as the same target.<br>
>><br>
> 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.<br>
<br>
I thought that MinGW worked with the system libc?<br>
<br>
-Chris<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>