Gentoo Archives: gentoo-dev

From: Austin English <wizardedit@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support
Date: Wed, 20 Apr 2016 19:32:03
Message-Id: 5717D909.9020108@gentoo.org
In Reply to: Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support by Mart Raudsepp
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4
5
6 On 04/20/2016 02:18 PM, Mart Raudsepp wrote:
7 > Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent
8 > Fredric:
9 >> On 21 April 2016 at 06:38, Ian Stakenvicius <axs@g.o>
10 >> wrote:
11 >>> Well so far the only needs I have run into for the win32 flag
12 >>> has been in relation to choosing UI toolkit support for cairo
13 >>> and gtk+ (and possibly others in the future), which is why I
14 >>> saw the parallel.
15 >>
16 >>
17 >> Given you're not using the flag to indicate "works on win32" as
18 >> such, but instead "compile using Win32 Widgets instead of
19 >> something else", wouldn't a better name indicate that somehow?
20 >>
21 >> The simplest thing I can think of that clears this confusion is
22 >> a few extra characters:
23 >>
24 >> "win32gui", "win32ui"
25 >>
26 >> Or something along those lines.
27 >>
28 >> It doesn't require us to know what the exact binding keywords in
29 >> microsoft terminology is used, and it clearly communicates
30 >> "This is something to do with User Interfaces" as opposed to
31 >> "Just linking/compiling slightly differently".
32 >
33 > win32 is what the base API seems to be called all over in the wild.
34 > The GTK+ configure flag is also --enable-win32-backend in gtk3 and
35 > --with-backend=win32 in gtk2 (didn't personally check the latter).
36 > Note that gtk configure actually also tracks platform_win32 and
37 > os_win32 in there, which are different things (and just
38 > configure.ac internal names). Former is true when host contains
39 > mingw, latter when host contains mingw or cygwin. When win32 gdk
40 > backend is enabled (which the propose USE flag would do), then it
41 > will depend on a matching cairo backend of that, to be able to do
42 > its own drawing on Windows. There's actually some stuff about
43 > pangowin32 as well, not sure Ian has noticed that yet.
44 >
45 > The GDK win32 backend uses what is called the win32 API. See e.g
46 > https://en.wikipedia.org/wiki/Windows_API#Versions For example a
47 > GdkWindow is created via CreateWindowExW, root of that
48 > documentation is apparently at
49 >
50 https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.8
51 5).aspx
52 >
53 > It doesn't use the Windows API higher level UI stuff, like
54 > wxWidgets does, but only the low-level stuff, and then emulating
55 > the themeing as best as it can right now, like Qt does. So in that
56 > way win32gui might be misleading. win32 or win32api or winapi or I
57 > dunno.
58 >
59 > Theoretically you can also build this stuff for consumption with
60 > wine. Or maybe ReactOS? Basically the only real point I have is
61 > that anything kernel_* to control this probably doesn't make
62 > sense.
63
64 Wine's dlls and programs (notepad/winemine/etc.) can be cross compiled
65 using mingw. It's mostly only useful for testing purposes (e.g.,
66 verifying that a certain wine dll also breaks an application the same
67 way on windows to confirm where the problem lies).
68
69 I used to build them regularly and upload to sourceforge, but haven't
70 in a while, as it seems there's little interest.
71
72 In addition, wine does use mingw if available for cross compiling its
73 test suite, but most users don't need/want that.
74
75 - -Austin
76 -----BEGIN PGP SIGNATURE-----
77 Version: GnuPG v2
78
79 iQIcBAEBCAAGBQJXF9kJAAoJEACzKVe5S/Ph+JIP/3l/spsw9AuanEbmKsYVIjg3
80 ErBs0omQ191mAPpovJWH0qejJaTAzneNbhXNIne8AE00L745rxensj4vtEunL9YU
81 QZ//nBNr2jGxX/SKmZqYn7A7+kgW9qXOVvYFWQebbyXy/DxhzMoTtP02Lvd/THyW
82 20W9kBS766/iuW6x6/qRRptbENMs2t3aR1B+JjB8OH/e/eAzU4RfnwuWI36D227S
83 56MgzuVbaY1ON+su9n/WhqjEdPitj9WaUDyxDNgglPfAcn6yVvlbXgN8CjsGo0cf
84 TleJhc2Kw0AYvt9V68D5oSt9l66ndC1/Zoy3r2fsboioCwqhhYI5SHWTC290iRc+
85 KbXOZJiCUIDahZ6YgiktkwmpODG9vb6hc9qVB7gKvX9gMZa6d9BFLxbs7lsvJ7eG
86 W/5ShV998tDSd63g1iKPtlyichUMQPCm5cmTVt4M3d0L19qadq4AKPr5Ap8N7dPC
87 YPpm8+m2FnC2iV4fFot7MTQSoJEmvWhXG8P50M/bKXyyzqRQqp+ntTE13hGILAsk
88 oeTdCJ/QyJrCMgJdhtjKXHcWcpAXjD0j3LbL8pRgVLiR7JtKoWOCEXvTzQRVixEz
89 rddxj+US3PUOFaEOLuJro7mNHHhUQanISeNQV2hOop0vBYdW9I8mL0UkfRWyjxR7
90 DPsjXwQYODQoJl1uWt/j
91 =MRRF
92 -----END PGP SIGNATURE-----