FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-10-2011, 09:38 PM
Pau Garcia i Quiles
 
Default The mingw* mess in Debian

On Thu, Nov 10, 2011 at 8:16 PM, Stephen Kitt <steve@sk2.org> wrote:

> I've thought
> about splitting the packages up, with separate 32- and 64-bit targets, but
> I'm not sure whether replacing and providing the mingw32 packages would be
> correct, since mingw-w64 isn't a drop-in replacement (the triplets are
> different). If that's not a problem then why not! The names for the 32-bit
> packages would probably be quite weird though since the upstream name is
> mingw-w64 (and I'd rather keep that in the package names...).

mingw-w64-i386 and mingw-w64-x64 are a bit ugly but still look sensible

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAKcBokvD1_r62r00TSHpnbO4rEakksqWq2zz61mb-UMLhf5b4w@mail.gmail.com">http://lists.debian.org/CAKcBokvD1_r62r00TSHpnbO4rEakksqWq2zz61mb-UMLhf5b4w@mail.gmail.com
 
Old 11-11-2011, 01:33 PM
Fabian Greffrath
 
Default The mingw* mess in Debian

Dear Stephen,


The history has been explained by others. I've been working for a while on
dropping at least gcc-mingw32; see #644769 which tracks the various packages
build-depending on gcc-mingw32 and/or mingw32. There are only three packages
left now; see #623400, #623402 and #623526. Patches are available for all the
bugs so NMUs should be straightforward if they're deemed necessary - I could
do the NMUs but I'd need a sponsor!


thank you very much for taking care of this. It's good to know that
you have already taken measures to drop the obsolete packages. How
about mingw32 (the one without gcc-) and friends?



mingw-w64-i386 and mingw-w64-x64 are a bit ugly but still look sensible


True, but mingw-w64-i686 and mingw-w64-x86_64 would even somehow match
the compilers' GNU tuples.


- Fabian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4EBD3253.8010802@greffrath.com">http://lists.debian.org/4EBD3253.8010802@greffrath.com
 
Old 11-24-2011, 04:45 AM
Stephen Kitt
 
Default The mingw* mess in Debian

Hi Fabian,

On Fri, 11 Nov 2011 15:33:55 +0100, Fabian Greffrath <fabian@greffrath.com>
wrote:
> > The history has been explained by others. I've been working for a while on
> > dropping at least gcc-mingw32; see #644769 which tracks the various
> > packages build-depending on gcc-mingw32 and/or mingw32. There are only
> > three packages left now; see #623400, #623402 and #623526. Patches are
> > available for all the bugs so NMUs should be straightforward if they're
> > deemed necessary - I could do the NMUs but I'd need a sponsor!
>
> thank you very much for taking care of this. It's good to know that
> you have already taken measures to drop the obsolete packages. How
> about mingw32 (the one without gcc-) and friends?

I'll let Ron handle mingw32's demise when the time comes... I noticed though
that the remaining reverse build-dependencies only used mingw32, not
gcc-mingw32, so I adjusted the various blocking relationships on #644769 and
#648306. gcc-mingw32 is no longer a build-dependency of any package in Debian
so I'll probably dispose of it with the next gcc-mingw-w64 upload (which
will include a transition package).

> > mingw-w64-i386 and mingw-w64-x64 are a bit ugly but still look sensible
>
> True, but mingw-w64-i686 and mingw-w64-x86_64 would even somehow match
> the compilers' GNU tuples.

I was thinking more along the lines of mingw-w64-win32 and mingw-w64-win64 so
that the API names appear in the package names. For people who know about
MinGW-w64 and its tuples the -i686 and -x86_64 approach would make sense, but
they already know to look for mingw-w64; for people who are looking for
Windows build tools it might be more helpful to actually mention win32 in the
32-bit packages (lots of people don't realise mingw-w64 targets 32-bit
Windows too; it seems the package description isn't sufficient).

Regards,

Stephen
 
Old 11-24-2011, 02:17 PM
Fabian Greffrath
 
Default The mingw* mess in Debian

gcc-mingw32 is no longer a build-dependency of any package in Debian
so I'll probably dispose of it with the next gcc-mingw-w64 upload (which
will include a transition package).


That's great news!


I was thinking more along the lines of mingw-w64-win32 and mingw-w64-win64 so
that the API names appear in the package names. For people who know about


The mingw-w64 project page's headline announces "GCC for both x64 &
x86 Windows", in the FAQ section they insist on using the GNU tuples
or talk about "32bit or 64bit windows" and in the Download section
they offer "Toolchains targetting Win32" and "Toolchains targetting
Win64". So it seems even upstream also lacks a consistent naming sheme. :/



32-bit packages (lots of people don't realise mingw-w64 targets 32-bit
Windows too; it seems the package description isn't sufficient).


Yes, the package descriptions might need some improvement. This is how
mingw-w64 introduces itself on its own project home page:


"The project's goal is to deliver runtime, headers, and libs for
developing 64 bit (x64), as well as 32 bit (x86), windows applications
using gcc-4.6 or newer versions."

<http://mingw-w64.sourceforge.net/>

i think that pretty much hits it.

- Fabian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ECE600C.4010706@greffrath.com">http://lists.debian.org/4ECE600C.4010706@greffrath.com
 
Old 11-24-2011, 02:17 PM
Fabian Greffrath
 
Default The mingw* mess in Debian

gcc-mingw32 is no longer a build-dependency of any package in Debian
so I'll probably dispose of it with the next gcc-mingw-w64 upload (which
will include a transition package).


That's great news!


I was thinking more along the lines of mingw-w64-win32 and mingw-w64-win64 so
that the API names appear in the package names. For people who know about


The mingw-w64 project page's headline announces "GCC for both x64 &
x86 Windows", in the FAQ section they insist on using the GNU tuples
or talk about "32bit or 64bit windows" and in the Download section
they offer "Toolchains targetting Win32" and "Toolchains targetting
Win64". So it seems even upstream also lacks a consistent naming sheme. :/



32-bit packages (lots of people don't realise mingw-w64 targets 32-bit
Windows too; it seems the package description isn't sufficient).


Yes, the package descriptions might need some improvement. This is how
mingw-w64 introduces itself on its own project home page:


"The project's goal is to deliver runtime, headers, and libs for
developing 64 bit (x64), as well as 32 bit (x86), windows applications
using gcc-4.6 or newer versions."

<http://mingw-w64.sourceforge.net/>

i think that pretty much hits it.

- Fabian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ECE6014.2000805@greffrath.com">http://lists.debian.org/4ECE6014.2000805@greffrath.com
 
Old 11-25-2011, 01:07 AM
Stephen Kitt
 
Default The mingw* mess in Debian

On Thu, 24 Nov 2011 16:17:32 +0100, Fabian Greffrath <fabian@greffrath.com>
wrote:
> > 32-bit packages (lots of people don't realise mingw-w64 targets 32-bit
> > Windows too; it seems the package description isn't sufficient).
>
> Yes, the package descriptions might need some improvement. This is how
> mingw-w64 introduces itself on its own project home page:
>
> "The project's goal is to deliver runtime, headers, and libs for
> developing 64 bit (x64), as well as 32 bit (x86), windows applications
> using gcc-4.6 or newer versions."
> <http://mingw-w64.sourceforge.net/>
>
> i think that pretty much hits it.

What I meant originally was more along the lines of "the package description
isn't sufficient, the package name has to be made clearer". Currently the
mingw-w64 package's description is

"MinGW-w64 provides a development and runtime environment for 32- and 64bit
Windows applications using the GNU Compiler Collection (gcc)."

which seems to me quite similar to the description you quote - the only
missing information is the x86/x64 nomenclature. It might also make sense to
mention the "Windows API" as it is now known (see
http://msdn.microsoft.com/en-us/library/Aa383723 for details).

I'm actually undecided regarding the -win32 and -win64 suffixes: while it's
probably a good thing to have at least win32 in the 32-bit package names,
using those two suffixes is restrictive at least in theory: the API itself is
pretty much the same, and Windows supports x86, x64 (x86_64), IA-64 (Itanium)
and presumably some form of ARM processors soon... So your original -i686 and
-x86_64 might be more future-proof. The MinGW-w64 project's site has links to
"WIN32" and "WIN64" downloads, but none of the packages use those terms. The
automated builds use "mingw-w32" for the 32-bit target package, "mingw-w64"
for the 64-bit target package, and i686/x86_64 is used to indicate the host
CPU! rubenvb's personal builds use i686-w64-mingw32/x86_64-w64-mingw32 to
specify the target, and sezero's follow the automated builds' naming
convention.

So there's precedent for using mingw-w32 and mingw-w64, but that would
probably generate more confusion with the similarity to mingw32. I'd vote for
mingw-w64-i686 and mingw-w64-x86_64 in the end, based on the following:
* the upstream project's name is MinGW-w64, hence the mingw-w64 name
* the target CPUs are currently i686 and x86_64
* we don't differentiate Win32 and Win64 because there's no real difference
in the APIs
* this allows future support for ARM and/or IA-64 without renaming existing
packages.
In the Windows world i?86 is known as x86 and x86_64 is x64, so those names
should appear in the description.

How about the following base description:

MinGW-w64 provides a development and runtime environment for 32- and 64-bit
(x86 and x64) Windows applications using the Windows API and the GNU
Compiler Collection (gcc).

This metapackage provides the full MinGW-w64 development environment.

(The binutils, gcc and gdb packages would be updated to suit.)

As far as the packages are concerned, the mingw-w64 source package would
produce mingw-w64, mingw-w64-i686, mingw-w64-x86_64, the corresponding three
-dev variants and a single -tools package (since that varies only by host
architecture); gcc-mingw-w64 would produce all the gcc-based packages
(gcc-mingw-w64, gcc-mingw-w64-i686, gcc-mingw-w64-x86_64; I'm also splitting
the package up into gcc, g++, gnat, gfortran etc.) including the transitional
gcc-mingw32 package; likewise binutils-mingw-w64 and gdb-mingw-w64.

Regards,

Stephen
 
Old 11-25-2011, 12:03 PM
Fabian Greffrath
 
Default The mingw* mess in Debian

probably generate more confusion with the similarity to mingw32. I'd vote for
mingw-w64-i686 and mingw-w64-x86_64 in the end, based on the following:


Me too!


How about the following base description:

MinGW-w64 provides a development and runtime environment for 32- and 64-bit
(x86 and x64) Windows applications using the Windows API and the GNU
Compiler Collection (gcc).


Sounds very good!


As far as the packages are concerned, the mingw-w64 source package would
produce mingw-w64, mingw-w64-i686, mingw-w64-x86_64, the corresponding three
-dev variants and a single -tools package (since that varies only by host


With "the corresponding three -dev variants" you mean a meta-package
mingw-w64-dev, which depends on both mingw-w64-i686-dev and
mingw-w64-x86_64-dev?



architecture); gcc-mingw-w64 would produce all the gcc-based packages
(gcc-mingw-w64, gcc-mingw-w64-i686, gcc-mingw-w64-x86_64; I'm also splitting


Will gcc-mingw-w64 also be a meta-package which depends on both
gcc-mingw-w64-i686 and gcc-mingw-w64-x86_64?



the package up into gcc, g++, gnat, gfortran etc.) including the transitional
gcc-mingw32 package; likewise binutils-mingw-w64 and gdb-mingw-w64.


On which package will the transitional gcc-mingw32 package depend? On
gcc-mingw-w64-i686 with compatibility symlinks to the binaries to take
account of the changed GNU tupel?


- Fabian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ECF9224.2020306@greffrath.com">http://lists.debian.org/4ECF9224.2020306@greffrath.com
 
Old 11-25-2011, 12:51 PM
Simon McVittie
 
Default The mingw* mess in Debian

On Fri, 25 Nov 2011 at 03:07:16 +0100, Stephen Kitt wrote:
> I'd vote for
> mingw-w64-i686 and mingw-w64-x86_64 in the end

It'll have to be x86-64 (or even x86.64) in package names, since _ isn't
allowed there, but the general principle seems OK.

There is precedent in the archive for replacing the _ with -, for instance
mlton-runtime-x86-64-linux-gnu and pcc-for-x86-64-linux-gnu.

S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111125135124.GA17710@reptile.pseudorandom.co.uk" >http://lists.debian.org/20111125135124.GA17710@reptile.pseudorandom.co.uk
 
Old 11-26-2011, 10:46 AM
Stephen Kitt
 
Default The mingw* mess in Debian

On Fri, 25 Nov 2011 14:03:32 +0100, Fabian Greffrath <fabian@greffrath.com>
wrote:
> > probably generate more confusion with the similarity to mingw32. I'd vote
> > for mingw-w64-i686 and mingw-w64-x86_64 in the end, based on the
> > following:
>
> Me too!

I'll go for that then, taking into account Simon's remark (so -x86-64).

> > How about the following base description:
> >
> > MinGW-w64 provides a development and runtime environment for 32- and
> > 64-bit (x86 and x64) Windows applications using the Windows API and the
> > GNU Compiler Collection (gcc).
>
> Sounds very good!

Excellent!

> > As far as the packages are concerned, the mingw-w64 source package would
> > produce mingw-w64, mingw-w64-i686, mingw-w64-x86_64, the corresponding
> > three -dev variants and a single -tools package (since that varies only
> > by host
>
> With "the corresponding three -dev variants" you mean a meta-package
> mingw-w64-dev, which depends on both mingw-w64-i686-dev and
> mingw-w64-x86_64-dev?

That's exactly what I had in mind.

> > architecture); gcc-mingw-w64 would produce all the gcc-based packages
> > (gcc-mingw-w64, gcc-mingw-w64-i686, gcc-mingw-w64-x86_64; I'm also
> > splitting
>
> Will gcc-mingw-w64 also be a meta-package which depends on both
> gcc-mingw-w64-i686 and gcc-mingw-w64-x86_64?

Yes.

> > the package up into gcc, g++, gnat, gfortran etc.) including the
> > transitional gcc-mingw32 package; likewise binutils-mingw-w64 and
> > gdb-mingw-w64.
>
> On which package will the transitional gcc-mingw32 package depend? On
> gcc-mingw-w64-i686 with compatibility symlinks to the binaries to take
> account of the changed GNU tupel?

To provide all the binaries in gcc-mingw32 it will have to depend on
{gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
compatibility symlinks you mention (and the usual /usr/share/doc contents).
It will pull in mingw-w64-i686-dev indirectly, and binutils-mingw-w64-i686
too.

As I understand it having the mingw-w64 package produce a gcc-mingw32 package
will make the gcc-mingw32 source package disappear eventually...

Regards,

Stephen
 
Old 11-28-2011, 07:34 AM
Fabian Greffrath
 
Default The mingw* mess in Debian

To provide all the binaries in gcc-mingw32 it will have to depend on
{gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
compatibility symlinks you mention (and the usual /usr/share/doc contents).
It will pull in mingw-w64-i686-dev indirectly, and binutils-mingw-w64-i686
too.


This sounds like a lot of packages to get lost in. Will you still get
*everything* if you install the mingw-w64 meta-package?



As I understand it having the mingw-w64 package produce a gcc-mingw32 package
will make the gcc-mingw32 source package disappear eventually...


A prior message to ftp-masters won't hurt, however.

- Fabian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ED34778.1040501@greffrath.com">http://lists.debian.org/4ED34778.1040501@greffrath.com
 

Thread Tools




All times are GMT. The time now is 12:27 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org