Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-21 Thread Mart Raudsepp 
Ühel kenal päeval, N, 21.04.2016 kell 15:42, kirjutas Ian Stakenvicius:
> b) -1 for making it global right now pending resolution of logistics
> for the profiles/base/use.mask entry,

I don't think it's unprecedented to just globally use.mask a USE flag
even if it's not declared a global USE flag.
Or more like it's common that architectures use.mask local flags used
in more than one place with a clear meaning it involved a dep they
don't want or can't keyword. Globally masking and unmasking in one
profile is kind of similar.
Those reading PMS or whatnot can speak up if needed, but I don't see a
problem here.
The discussion is useful, as I suspect we can get sufficient users soon
enough, especially if you look into some of the other GUI stuff that
can work there (e.g gitg/gedit), though the question is what's the real
use of having any of these if upstream isn't looking into making use of
this to build their windows binaries or whatnot.

> c) rejection for the proposed ebuild patches pending a toolkit
> refactoring to be determined later.

Not really a rejection, it's just that I haven't looked into those
patches with a review mind as of yet. It just sounds like it's worth
looking at it deeper, that maybe there's more extensive improvement
possibilities. So just not an ACK as of yet.

> 
> B and C make most of this thread pretty well moot, I guess, but
> following A, can we decide that USE="winapi" could be a good flag
> name?  If nobody objects I'll use that when leio and I work on the
> refactoring of gtk+ and likely try to use local flags somehow for
> now.

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-21 Thread Ian Stakenvicius 
On 21/04/16 11:31 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, K, 20.04.2016 kell 22:18, kirjutas Mart Raudsepp:
>> Basically the only real point I have is that anything kernel_* to
>> control this probably doesn't make sense.
>>
> 
> Oh, just to clarify and avoid misunderstanding:
> I did not intend to ack the changes to gdk-pixbuf and gtk+ with my
> message, even if the flag name is changed.
> It sounds to me like we have some refactoring to do in those ebuilds
> together with aqua in mind as well, once we have agreed on the future
> global USE flag name.
> I also vote 'no' to the profiles changes, because we don't have 6+
> packages with the flag yet to make it global use flag quite yet (though
> it would make sense once we do, and in essence it is a global one that
> needs masking in other profiles, etc - fiddly with local use flag).
> 
> Once this thread has concluded on a naming, I'm sure we can have a
> productive gtk/gdk-pixbuf review via IRC :)
> 
> 
> Mart
> 


Ok, so to summarize:

a) +1 for a USE flag instead of KERNEL/ELIBC (that's 4 in favour, 2
against i think?)

b) -1 for making it global right now pending resolution of logistics
for the profiles/base/use.mask entry,

c) rejection for the proposed ebuild patches pending a toolkit
refactoring to be determined later.


B and C make most of this thread pretty well moot, I guess, but
following A, can we decide that USE="winapi" could be a good flag
name?  If nobody objects I'll use that when leio and I work on the
refactoring of gtk+ and likely try to use local flags somehow for now.









signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-21 Thread Mart Raudsepp 
Ühel kenal päeval, K, 20.04.2016 kell 22:18, kirjutas Mart Raudsepp:
> Basically the only real point I have is that anything kernel_* to
> control this probably doesn't make sense.
> 

Oh, just to clarify and avoid misunderstanding:
I did not intend to ack the changes to gdk-pixbuf and gtk+ with my
message, even if the flag name is changed.
It sounds to me like we have some refactoring to do in those ebuilds
together with aqua in mind as well, once we have agreed on the future
global USE flag name.
I also vote 'no' to the profiles changes, because we don't have 6+
packages with the flag yet to make it global use flag quite yet (though
it would make sense once we do, and in essence it is a global one that
needs masking in other profiles, etc - fiddly with local use flag).

Once this thread has concluded on a naming, I'm sure we can have a
productive gtk/gdk-pixbuf review via IRC :)


Mart

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Ian Stakenvicius 

> On Apr 20, 2016, at 6:51 PM, Andrew Udvare  wrote:
> 
>> On 20/04/16 12:58, Ian Stakenvicius wrote:
>> On 20/04/16 03:41 PM, Anthony G. Basile wrote:
 According to 'file' the binary format is actually "PE32 executable
 (console) Intel 80386, for MS Windows" for a random *.exe file in my
 /usr/i686-w64-mingw32/usr/bin
> 
> That is because Mingw is for making native executables for Windows, not
> ELF files.

I believe blueness' point here was that with Windows 10's support of ELF, one 
might be able to build a say, winapi toolkit gtk+:3 directly in Linux without 
needing a mingw cross-toolchain.  That is, linking this back to the original 
point, it's best to not mix up the meaning of this use flag with the executable 
file format.

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Andrew Udvare 
On 20/04/16 12:58, Ian Stakenvicius wrote:
> On 20/04/16 03:41 PM, Anthony G. Basile wrote:
>>> According to 'file' the binary format is actually "PE32 executable
>>> (console) Intel 80386, for MS Windows" for a random *.exe file in my
>>> /usr/i686-w64-mingw32/usr/bin

That is because Mingw is for making native executables for Windows, not
ELF files. I do not recall Gentoo Prefix supporting Mingw in a
meaningful way (it supports Cygwin IIRC). It sounds like a bit of work,
but I sure would like to see it. The problem is still that on Windows,
cmd is terrible and mintty only gives a partial solution to having such
bad terminals. Viability seems very low as every one who uses Mingw
seems to have mostly their own undocumented ways to get things to work.
You can find this pattern among many open source projects.

>> yes and while it is reported by `file` as PE32, it is sometimes referred
>> to as just win32.  its proper name, if i recall correctly is "Win32
>> Portable Executable File Format".  it is the equivalent of ELF, COFF and
>> a.out in the Linux world and Mach-O in the Mac world.  basically its the
>> format the linker/loader is looking for.

PE is essentially COFF with extensions applied. On top of that PE+ came
around the time of Windows Vista, and the format is not readable by
prior Windows versions like XP. Interestingly, even on a non-x86
platform the file will still have the MS-DOS stub (you can see this in
an XEX for Xbox 360).

Realistically, you only need to call it PE since XP is so dead.

>> with gentoo portage in there, i think
>> we'll expand in to a whole new market.

It is not easy. Ubuntu has always had trouble with Gentoo Prefix due to
a 'broken' toolchain that is kind of Debian-specific. A Debian-specific
bootstrap has to be made for this to work.

Andrew



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Ian Stakenvicius 
On 20/04/16 03:41 PM, Anthony G. Basile wrote:
> On 4/20/16 3:30 PM, Ian Stakenvicius wrote:
>> On 20/04/16 03:01 PM, Anthony G. Basile wrote:
>>
>>> 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
>>
>>> 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.
>>
>>
>>
>> According to 'file' the binary format is actually "PE32 executable
>> (console) Intel 80386, for MS Windows" for a random *.exe file in my
>> /usr/i686-w64-mingw32/usr/bin
>>
>> I assume PE32 would be the label one would use if comparing to ELF ?
>>
> 
> yes and while it is reported by `file` as PE32, it is sometimes referred
> to as just win32.  its proper name, if i recall correctly is "Win32
> Portable Executable File Format".  it is the equivalent of ELF, COFF and
> a.out in the Linux world and Mach-O in the Mac world.  basically its the
> format the linker/loader is looking for.
> 
> if i've understood the plans for windows 10, its kernel will be able to
> link/load native ELF and execute Linux system calls, at least for amd64
> arch/abi.  I saw a demonstration with ubuntu userland, but i'm sure it
> will be able to handle gentoo.  with gentoo portage in there, i think
> we'll expand in to a whole new market.
> 
> not meaning to steal your thread, but i think keeping the namespace
> precise here will help us avoid collisions in the future.
> 
> 

Right, so a +1 for USE="winapi" then?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Anthony G. Basile 
On 4/20/16 3:30 PM, Ian Stakenvicius wrote:
> On 20/04/16 03:01 PM, Anthony G. Basile wrote:
> 
>> 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
> 
>> 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.
> 
> 
> 
> According to 'file' the binary format is actually "PE32 executable
> (console) Intel 80386, for MS Windows" for a random *.exe file in my
> /usr/i686-w64-mingw32/usr/bin
> 
> I assume PE32 would be the label one would use if comparing to ELF ?
> 

yes and while it is reported by `file` as PE32, it is sometimes referred
to as just win32.  its proper name, if i recall correctly is "Win32
Portable Executable File Format".  it is the equivalent of ELF, COFF and
a.out in the Linux world and Mach-O in the Mac world.  basically its the
format the linker/loader is looking for.

if i've understood the plans for windows 10, its kernel will be able to
link/load native ELF and execute Linux system calls, at least for amd64
arch/abi.  I saw a demonstration with ubuntu userland, but i'm sure it
will be able to handle gentoo.  with gentoo portage in there, i think
we'll expand in to a whole new market.

not meaning to steal your thread, but i think keeping the namespace
precise here will help us avoid collisions in the future.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Austin English 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 04/20/2016 02:18 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent 
> Fredric:
>> On 21 April 2016 at 06:38, Ian Stakenvicius  
>> wrote:
>>> 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.
>> 
>> 
>> Given you're not using the flag to indicate "works on win32" as 
>> such, but instead "compile using Win32 Widgets instead of 
>> something else", wouldn't a better name indicate that somehow?
>> 
>> The simplest thing I can think of that clears this confusion is
>> a few extra characters:
>> 
>> "win32gui", "win32ui"
>> 
>> Or something along those lines.
>> 
>> It doesn't require us to know what the exact binding keywords in
>>  microsoft terminology is used, and it clearly communicates
>> "This is something to do with User Interfaces" as opposed to
>> "Just linking/compiling slightly differently".
> 
> win32 is what the base API seems to be called all over in the wild.
> The GTK+ configure flag is also --enable-win32-backend in gtk3 and
> --with-backend=win32 in gtk2 (didn't personally check the latter).
> Note that gtk configure actually also tracks platform_win32 and
> os_win32 in there, which are different things (and just
> configure.ac internal names). Former is true when host contains
> mingw, latter when host contains mingw or cygwin. When win32 gdk
> backend is enabled (which the propose USE flag would do), then it
> will depend on a matching cairo backend of that, to be able to do
> its own drawing on Windows. There's actually some stuff about 
> pangowin32 as well, not sure Ian has noticed that yet.
> 
> The GDK win32 backend uses what is called the win32 API. See e.g 
> https://en.wikipedia.org/wiki/Windows_API#Versions For example a 
> GdkWindow is created via CreateWindowExW, root of that 
> documentation is apparently at
> 
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.8
5).aspx
> 
> It doesn't use the Windows API higher level UI stuff, like 
> wxWidgets does, but only the low-level stuff, and then emulating 
> the themeing as best as it can right now, like Qt does. So in that 
> way win32gui might be misleading. win32 or win32api or winapi or I 
> dunno.
> 
> Theoretically you can also build this stuff for consumption with 
> wine. Or maybe ReactOS? Basically the only real point I have is 
> that anything kernel_* to control this probably doesn't make 
> sense.

Wine's dlls and programs (notepad/winemine/etc.) can be cross compiled
using mingw. It's mostly only useful for testing purposes (e.g.,
verifying that a certain wine dll also breaks an application the same
way on windows to confirm where the problem lies).

I used to build them regularly and upload to sourceforge, but haven't
in a while, as it seems there's little interest.

In addition, wine does use mingw if available for cross compiling its
test suite, but most users don't need/want that.

- -Austin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXF9kJAAoJEACzKVe5S/Ph+JIP/3l/spsw9AuanEbmKsYVIjg3
ErBs0omQ191mAPpovJWH0qejJaTAzneNbhXNIne8AE00L745rxensj4vtEunL9YU
QZ//nBNr2jGxX/SKmZqYn7A7+kgW9qXOVvYFWQebbyXy/DxhzMoTtP02Lvd/THyW
20W9kBS766/iuW6x6/qRRptbENMs2t3aR1B+JjB8OH/e/eAzU4RfnwuWI36D227S
56MgzuVbaY1ON+su9n/WhqjEdPitj9WaUDyxDNgglPfAcn6yVvlbXgN8CjsGo0cf
TleJhc2Kw0AYvt9V68D5oSt9l66ndC1/Zoy3r2fsboioCwqhhYI5SHWTC290iRc+
KbXOZJiCUIDahZ6YgiktkwmpODG9vb6hc9qVB7gKvX9gMZa6d9BFLxbs7lsvJ7eG
W/5ShV998tDSd63g1iKPtlyichUMQPCm5cmTVt4M3d0L19qadq4AKPr5Ap8N7dPC
YPpm8+m2FnC2iV4fFot7MTQSoJEmvWhXG8P50M/bKXyyzqRQqp+ntTE13hGILAsk
oeTdCJ/QyJrCMgJdhtjKXHcWcpAXjD0j3LbL8pRgVLiR7JtKoWOCEXvTzQRVixEz
rddxj+US3PUOFaEOLuJro7mNHHhUQanISeNQV2hOop0vBYdW9I8mL0UkfRWyjxR7
DPsjXwQYODQoJl1uWt/j
=MRRF
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Ian Stakenvicius 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/04/16 03:01 PM, Anthony G. Basile wrote:
> 
> 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
> 
> 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.
> 


According to 'file' the binary format is actually "PE32 executable
(console) Intel 80386, for MS Windows" for a random *.exe file in my
/usr/i686-w64-mingw32/usr/bin

I assume PE32 would be the label one would use if comparing to ELF ?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcX2OEACgkQAJxUfCtlWe1mQQD/QrwFeMpuh0spKgwmA7d5Khhw
LpZ1RFtG2anVsyMrYn0A/Rmde/6Tw2ufvARI2+nCnKShVxDtrU3JbREr2KYrnLYI
=Cja7
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Ian Stakenvicius 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/04/16 03:18 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent
> Fredric:
>> On 21 April 2016 at 06:38, Ian Stakenvicius 
>> wrote:
>>> 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.
>> 
>> 
>> Given you're not using the flag to indicate "works on win32" as
>> such, but instead "compile using Win32 Widgets instead of
>> something else", wouldn't a better name indicate that somehow?
>> 
>> The simplest thing I can think of that clears this confusion is
>> a few extra characters:
>> 
>> "win32gui", "win32ui"
>> 
>> Or something along those lines.
>> 
>> It doesn't require us to know what the exact binding keywords
>> in microsoft terminology is used, and it clearly communicates
>> "This is something to do with User Interfaces" as opposed to
>> "Just linking/compiling slightly differently".
> 
> win32 is what the base API seems to be called all over in the
> wild. The GTK+ configure flag is also --enable-win32-backend in
> gtk3 and --with-backend=win32 in gtk2 (didn't personally check
> the latter). Note that gtk configure actually also tracks
> platform_win32 and os_win32 in there, which are different things
> (and just configure.ac internal names). Former is true when host
> contains mingw, latter when host contains mingw or cygwin. When
> win32 gdk backend is enabled (which the propose USE flag would 
> do), then it will depend on a matching cairo backend of that, to
> be able to do its own drawing on Windows. There's actually some
> stuff about pangowin32 as well, not sure Ian has noticed that
> yet.
> 
> The GDK win32 backend uses what is called the win32 API. See e.g 
> https://en.wikipedia.org/wiki/Windows_API#Versions For example a
> GdkWindow is created via CreateWindowExW, root of that 
> documentation is apparently at 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=
vs.85).aspx
>
>  It doesn't use the Windows API higher level UI stuff, like
> wxWidgets does, but only the low-level stuff, and then emulating
> the themeing as best as it can right now, like Qt does. So in
> that way win32gui might be misleading. win32 or win32api or
> winapi or I dunno.


USE="winapi" is likely a better flag name, if others agree (and also
agree to the necessity of the flag) then I'll switch to that.


> 
> Theoretically you can also build this stuff for consumption with
> wine. Or maybe ReactOS? Basically the only real point I have is
> that anything kernel_* to control this probably doesn't make
> sense.


I can confirm what I've built with my mingw-crossdev works under
wine; no idea on ReactOS but I don't see why it wouldn't.  That
said, I expect anything built to run on a 'kernel_Winnt' would run
on both anyways so I may well have undone your point. :)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcX134ACgkQAJxUfCtlWe1g1gD9GlVY1GlsHSkOhBtR3RTJKpqp
pgE3HtSptJpb9gz7zQoA/21XSnNGzs3+/UOagD+R3pRe5cHaUGRSv8m0MN7wAcYF
=4Uoi
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Mart Raudsepp 
Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent Fredric:
> On 21 April 2016 at 06:38, Ian Stakenvicius  wrote:
> > 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.
> 
> 
> Given you're not using the flag to indicate "works on win32" as such,
> but instead "compile using Win32 Widgets instead of something else",
> wouldn't a better name indicate that somehow?
> 
> The simplest thing I can think of that clears this confusion is a few
> extra characters:
> 
>   "win32gui", "win32ui"
> 
> Or something along those lines.
> 
> It doesn't require us to know what the exact binding keywords in
> microsoft terminology is used, and it clearly communicates "This is
> something to do with User Interfaces" as opposed to "Just
> linking/compiling slightly differently".

win32 is what the base API seems to be called all over in the wild.
The GTK+ configure flag is also --enable-win32-backend in gtk3 and
--with-backend=win32 in gtk2 (didn't personally check the latter).
Note that gtk configure actually also tracks platform_win32 and
os_win32 in there, which are different things (and just configure.ac
internal names). Former is true when host contains mingw, latter when
host contains mingw or cygwin.
When win32 gdk backend is enabled (which the propose USE flag would
do), then it will depend on a matching cairo backend of that, to be
able to do its own drawing on Windows. There's actually some stuff
about pangowin32 as well, not sure Ian has noticed that yet.

The GDK win32 backend uses what is called the win32 API. See e.g
https://en.wikipedia.org/wiki/Windows_API#Versions
For example a GdkWindow is created via CreateWindowExW, root of that
documentation is apparently at
https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx

It doesn't use the Windows API higher level UI stuff, like wxWidgets
does, but only the low-level stuff, and then emulating the themeing as
best as it can right now, like Qt does. So in that way win32gui might
be misleading. win32 or win32api or winapi or I dunno.

Theoretically you can also build this stuff for consumption with wine.
Or maybe ReactOS?
Basically the only real point I have is that anything kernel_* to
control this probably doesn't make sense.


Mart

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Anthony G. Basile 
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).

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

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.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Kent Fredric 
On 21 April 2016 at 06:38, Ian Stakenvicius  wrote:
> 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.


Given you're not using the flag to indicate "works on win32" as such,
but instead "compile using Win32 Widgets instead of something else",
wouldn't a better name indicate that somehow?

The simplest thing I can think of that clears this confusion is a few
extra characters:

  "win32gui", "win32ui"

Or something along those lines.

It doesn't require us to know what the exact binding keywords in
microsoft terminology is used, and it clearly communicates "This is
something to do with User Interfaces" as opposed to "Just
linking/compiling slightly differently".

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Ian Stakenvicius 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/04/16 02:22 PM, M. J. Everitt wrote:
> On 20/04/16 19:17, Mike Frysinger wrote:
>> agreed ... we have kernel_Winnt & elibc_Winnt already.  i
>> think those represent a mingw environment (vs a cygwin env).
> Surely 'winnt' is a somewhat out-of-date and potentially
> confusing flag? Can't we migrate to a win32 and win64 as
> pertaining to current/recent architectures, and directly relating
> to mingw32 and mingw64 or such-like?!
> 
> Sooner or later win32 is going to be EOL (as the operating
> systems themselves soon will be) ...
> 

kernel_Winnt may seem old but it's accurate in comparison with
kernel_DOS, which would be its predecessor if we had ever attempted
to support it -- the executable is still NTKRNL*.exe or NTOSKRNL.exe
after all, right?

Recall this isn't the ARCH, which can still be either x86 or amd64
(ie x86_64).

The win32 flag I was proposing here was relating to the UI toolkit,
which is likely (i'm guessing) called win32 for legacy reasons
rather than explicitly being 32bit, given I expect the 64bit toolkit
has more or less the same API -- again, not 32bit-windows vs
64-bit-windows related.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcXzvUACgkQAJxUfCtlWe2ezQEAyWMp3J7msrHqQbqZH/Ww1bXe
pXY0rkEcC0nW7nq6TiUA/Ry56nWOGVobygHia+4bP7b9fomnPha39GdLLZyvafS5
=SEOj
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Ian Stakenvicius 
-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-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread M. J. Everitt 
On 20/04/16 19:17, Mike Frysinger wrote:
> agreed ... we have kernel_Winnt & elibc_Winnt already.  i think
> those represent a mingw environment (vs a cygwin env).
Surely 'winnt' is a somewhat out-of-date and potentially confusing flag?
Can't we migrate to a win32 and win64 as pertaining to current/recent
architectures, and directly relating to mingw32 and mingw64 or such-like?!

Sooner or later win32 is going to be EOL (as the operating systems
themselves soon will be) ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Alon Bar-Lev 
On 20 April 2016 at 18:52, Ian Stakenvicius  wrote:
>
> Hi everyone:
>
> 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...

[gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

2016-04-20 Thread Ian Stakenvicius 
Hi everyone:

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?
commit 120335a6721cbcee6f92303c8a6d7cb6cc77b36e
Author: Ian Stakenvicius 
Date:   Tue Apr 19 15:00:07 2016 -0400

Add USE="win32" to profile, x11-libs/cairo, and x11-libs/gtk+

Similar to USE="aqua", the addition of the win32 use flag allows easier
prefix and crossdev-based building of packages targeting windows (win32)
environments.

This commit adds the flag to profiles/use.desc, and masks it for all
profiles via profiles/base/use.mask.  This leaves the flag available
to be used optionally via the embedded profile, which does not inherit
from base.

Additionally, the commit adds IUSE="win32" support to x11-libs/gtk+ and
its depenency, x11-libs/cairo.  Other packages may follow in future commits.

Package-Manager: portage-2.2.26

diff --git a/profiles/base/use.mask b/profiles/base/use.mask
index 3127dad..f5bd582 100644
--- a/profiles/base/use.mask
+++ b/profiles/base/use.mask
@@ -2,6 +2,10 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
+# Ian Stakenvicius  (19 Apr 2016)
+# USE flag(s) specific to Windows (for mingw, cygwin, etc)
+win32
+
 # Brian Evans  (2 Dec 2015)
 # php 5.4 is end of life, masked for removal
 php_targets_php5-4
diff --git a/profiles/use.desc b/profiles/use.desc
index 6acf19f..49eb30f 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -371,6 +371,7 @@ wavpack - Add support for wavpack audio compression tools
 wddx - Add support for Web Distributed Data eXchange
 webkit - Add support for the WebKit HTML rendering/layout engine
 wifi - Enable wireless network functions
+win32 - Include support for the Windows GUI (for mingw or cygwin)
 wmf - Add support for the Windows Metafile vector image format
 wxwidgets - Add support for wxWidgets/wxGTK GUI toolkit
 x264 - Enable h264 encoding using x264
diff --git a/x11-libs/cairo/cairo-1.14.2-r1.ebuild b/x11-libs/cairo/cairo-1.14.2-r1.ebuild
index 12d34b3..3f8aa88 100644
--- a/x11-libs/cairo/cairo-1.14.2-r1.ebuild
+++ b/x11-libs/cairo/cairo-1.14.2-r1.ebuild
@@ -19,7 +19,7 @@ DESCRIPTION="A vector graphics library with cross-device output support"
 HOMEPAGE="http://cairographics.org/;
 LICENSE="|| ( LGPL-2.1 MPL-1.1 )"
 SLOT="0"
-IUSE="X aqua debug directfb gles2 +glib opengl static-libs +svg valgrind xcb xlib-xcb"
+IUSE="X aqua debug directfb gles2 +glib opengl static-libs +svg valgrind win32 xcb xlib-xcb"
 # gtk-doc regeneration doesn't seem to work with out-of-source builds
 #[[ ${PV} == ** ]] && IUSE="${IUSE} doc" # API docs are provided in tarball, no need to regenerate
 
@@ -128,6 +128,7 @@ multilib_src_configure() {
 		$(use_enable static-libs static) \
 		$(use_enable svg) \
 		$(use_enable valgrind) \
+		$(use_enable win32) \
 		$(use_enable xcb) \
 		$(use_enable xcb xcb-shm) \
 		$(use_enable xlib-xcb) \
 		$(use_enable xlib-xcb) \
diff --git a/x11-libs/gtk+/gtk+-2.24.29.ebuild b/x11-libs/gtk+/gtk+-2.24.29.ebuild
index bef80a7..5bfda5c 100644
--- a/x11-libs/gtk+/gtk+-2.24.29.ebuild
+++ b/x11-libs/gtk+/gtk+-2.24.29.ebuild
@@ -13,9 +13,10 @@ HOMEPAGE="http://www.gtk.org/;
 
 LICENSE="LGPL-2+"
 SLOT="2"
-IUSE="aqua cups examples +introspection test vim-syntax xinerama"
+IUSE="aqua cups examples +introspection test vim-syntax win32 xinerama"
 REQUIRED_USE="
-	xinerama? ( !aqua )
+	xinerama? ( !aqua !win32 )
+	aqua? ( !win32 )
 "
 
 KEYWORDS="~alpha amd64 ~arm ~arm64 hppa ~ia64 ~mips ~ppc ppc64 ~s390 ~sh ~sparc x86 ~amd64-fbsd ~x86-fbsd ~x86-freebsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
@@ -25,14 +26,14 @@ COMMON_DEPEND="
 	>=dev-libs/atk-2.10.0[introspection?,${MULTILIB_USEDEP}]
 	>=dev-libs/glib-2.34.3:2[${MULTILIB_USEDEP}]
 	>=media-libs/fontconfig-2.10.92[${MULTILIB_USEDEP}]
-	>=x11-libs/cairo-1.12.14-r4:=[aqua?,svg,${MULTILIB_USEDEP}]
+