Huh ok. Well, I guess it too is its own OS or architecture. Does anyone know how dlang or another language that grew-up-on-windows-then-got-ported-to-gcc-and-llvm handles this?
-Chris
···
On May 3, 2016, at 9:43 PM, Joe Groff <jgroff@apple.com> wrote:
On May 3, 2016, at 9:40 PM, Chris Lattner <clattner@apple.com> wrote:
On May 3, 2016, at 9:39 PM, Joe Groff <jgroff@apple.com> wrote:
On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution <swift-evolution@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?
There's no such thing on Windows (at least, until Windows 10, which introduced yet another "universal" C runtime). Older versions of mingw used to link against MSVCRT.DLL, which was an unsupported vintage C runtime intended for SPI use only, but now use their own glibc-derived C library.
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@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: Conditional Compilation - D Programming Language. 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@swift.org> wrote:
> On May 3, 2016, at 9:39 PM, Joe Groff <jgroff@apple.com> wrote:
>
>
>> On May 3, 2016, at 9:27 PM, Chris Lattner via swift-evolution < >> swift-evolution@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.