On 04/20/2016 09:01 PM, Anthony G. Basile wrote: > On 4/20/16 2:17 PM, Mike Frysinger wrote: >> On 20 Apr 2016 21:01, Alon Bar-Lev wrote: >>> On 20 April 2016 at 18:52, Ian Stakenvicius wrote: >>>> >>>> Comments? >>> >>> You should be able to achieve similar behavior by looking at libc >>> and/or CHOST without introducing new USE flag, just like we do for >>> aix/solaris/freebsd etc... >> >> agreed ... we have kernel_Winnt & elibc_Winnt already. i think >> those represent a mingw environment (vs a cygwin env).
Nope: We have used kernel_Winnt and elibc_Winnt for the native MS Visual Studio compiler, wrapped with Parity[1] to provide a gcc-like commandline interface for the toolchain. Independent of Parity I've seen traces of native cl.exe/lib.exe support within libtool as well. [1] https://github.com/haubi/parity > The way I think of it is > > the operating system (ie kernel) = kernel_Winnt > the system libraries (=~libc) = elibc_Winnt > the executable binary format = win32 Right now, for kernel_Winnt, in the prefix/windows profiles we have: + elibc_Interix . runtime environment: Interix libc, CHOST=i586-pc-interixN.N . python+bash+portage: yes . accessible API (UI): POSIX (X11 client) . executable format : PE32 executable for MS Windows (POSIX) Intel 80386 32-bit . compiler: GNU gcc . used as : build environment for elibc_Winnt: CBUILD=CHOST=i586-pc-winntN.N (non-cross) . state : dead, but in production here + elibc_Winnt (32bit only for now) . runtime environment: MSVCRT, CHOST=i586-pc-winntN.N . python+bash+portage: no . accessible API (UI): Win32 (Win32) . executable format : PE32 executable for MS Windows ({console,GUI}) Intel 80386 32-bit . compiler: MSVC cl.exe (wrapped by Parity) . used as : runtime environment for my company's application . state : old, in production here, to be updated + elibc_Cygwin . runtime environment: newlib (Cygwin), CHOST={i686,x86_64}-pc-cygwin . python+bash+portage: yes . accessible API (UI): POSIX (X11 client), Win32 (Win32) . executable format : PE32 executable ({console,GUI}) Intel 80386, for MS Windows PE32+ executable ({console,GUI}) x86_64, for MS Windows . compiler: GNU gcc . used as : build environment for elibc_Winnt: CBUILD=CHOST=i586-pc-winnt (non-cross) build environment for elibc_Mingw: CBUILD=CHOST={i686,x86_64}-w64-mingw32 (non-cross) . state : under construction, cygwin fork patch necessary (upstream review pending) For MinGW, IMHO it feels more straightforward to add something like: + elibc_Mingw (mingw-w64.org I guess, not mingw.org) . runtime environment: MinGW-W64, CHOST={i686,x86_64}-w64-mingw32 . python+bash+portage: no . accessible API (UI): Win32 (Win32) . executable format : PE32 executable ({console,GUI}) Intel 80386, for MS Windows PE32+ executable ({console,GUI}) x86_64, for MS Windows . compiler: GNU gcc . used as : runtime environment for various applications . state : proposal > I don't know that we need an executable binary format flag, but we might > because they're working on windows 10 so it can natively run ELF. Well, nope: Although Windows Desktop (only, not Windows Server) can run ELF somewhat "natively", it is not possible to start Windows executables from within a Linux executable. This makes me assume there is no access to the Win32 API from within Linux either. Also, they explicitly focus on the commandline only, not the GUI. So WSL (Windows Subsystem for Linux) does not seem to be useable as replacement for any of these currently possible non-crosscompiling setups: * Interix/Cygwin building Winnt (.exe runs natively) * Interix/Cygwin building Mingw (.exe runs natively) * Linux building Mingw (.exe runs in Wine) For the USE flag: As Cygwin allows for both X11 and Win32 UI, I do see fit for an additional "win32ui" or similar (win32gui, w32ui, w32gui, winui, wingui, wntui, wntgui) USE flag. And what about the new "win8ui" (formerly called Metro): Do/will GTK+, Qt and others support that too eventually? Probably we may end up with something like: IUSE="X aqua win32ui win8ui" My 2*2 cents, /haubi/
