-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 20/04/16 02: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: >>> After doing some experimentation with a mingw crossdev, I >>> found that I needed to do a lot of EXTRA_ECONF settings in >>> combination with USE="aqua" in order to get packages >>> supporting a win32 API to be configured appropriately. In >>> order to support this situation better, I propose adding a >>> new global flag 'win32', modelled after the 'aqua' flag, that >>> can be used instead to provide this configuration directly in >>> ebuilds. >>> >>> Just like USE="aqua", the flag will be use.mask'ed in base/ >>> so that users don't erroneously enable it. I didn't >>> un-use.mask it anywhere yet since (A) I don't have a >>> prefix/windows environment to test, and (B) the mingw-based >>> crossdev environments use profiles/embedded by default, which >>> doesn't inherit from profiles/base and so doesn't have the >>> use.mask restriction. >>> >>> The attached patch lists the necessary changes to profile/ as >>> well as the addition of USE=win32 to *ONE VERSION* of gtk+:2, >>> gtk+:3 and cairo (the actual commit will include more >>> versions). >>> >>> 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). > > i don't think a parallel to aqua makes sense. aqua is a specific > UI toolkit in OS X. it's more parallel to something like GTK+ or > QT. > > further, nesting aqua/win32 doesn't make sense as there is no > valid profile where both flags would be available. USE=aqua can > only be turned on in an OS X profile where your proposed > USE=win32 would be masked (and vice versa). -mike >
Well so far the only needs I have run into for the win32 flag has been in relation to choosing UI toolkit support for cairo and gtk+ (and possibly others in the future), which is why I saw the parallel. For my specific needs (mingw cross-compilation), yes leveraging elibc_mingw would more than suffice, however there may be other cases where configuring for the 'win32' or 'windows' UI toolkit makes sense too -- apparently someone's built gtk+ for the win32 toolkit instead of X in cygwin and is distributing binaries (both KERNEL and ELIBC differ there iirc), and I expect both the prefix/windows/winnt or prefix/windows/Interix profiles would likely benefit from this configuration too, but both of those iirc use different ELIBC values compared to mingw. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlcXzJ0ACgkQAJxUfCtlWe0fkQEAugAyzxifYKxh+R8ocgZoL1nB 3SdR9gfDjlOqkBsqBO0A/2ZdubaDowXVg7bVrfkVfZWJF5/c8aZ+5I9wyHkjKHzd =6/5H -----END PGP SIGNATURE-----
