On Thu, 24 Nov 2011 16:17:32 +0100, Fabian Greffrath <fab...@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
signature.asc
Description: PGP signature
