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