[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation on W32

From: Eli Zaretskii
Subject: Re: Documentation on W32
Date: Sat, 15 Sep 2012 13:43:17 +0300

> Date: Sat, 15 Sep 2012 12:14:10 +0200
> From: Nikos Mavrogiannopoulos <address@hidden>
> CC: address@hidden, address@hidden
> On 09/15/2012 11:49 AM, Eli Zaretskii wrote:
> >> Date: Sat, 15 Sep 2012 11:18:48 +0200
> >> From: Nikos Mavrogiannopoulos <address@hidden>
> >> Cc: address@hidden
> >>
> >> Is there any reason for not using mingw64-32 instead?
> > 
> > Why would a package force its users into using only one particular
> > brand of runtime?
> The question is to determine whether there is a reason to actually
> support mingw32 given the fact that's broken with several functions
> we need.

mingw32 is _not_ broken, far from that.  It is just somewhat slow in
catching up with the latest MS headers and functions, that's all.

Mingw32 is currently the _only_ package that allows building software
packages that use autoconf on Windows platforms, without extensive
tinkering with the infrastructure (such as the shell used to run the
scripts and Makefiles) or recompiling lots of basic libraries that are
already available in precompiled form from the MinGW site.  That site
provides everything that is needed:

 . MSYS, which is required to run autoconf and the resulting Makefiles

 . GCC, Binutils, GDB, and the rest of the tools needed for building
   and debugging programs natively

 . libraries such as libiconv, libintl, zlib, etc., which are needed
   by many packages, GnuTLS included

All of these work together rather well after a very simple setup step.
All the alternatives need a much more complex configuration, or don't
run natively on Windows at all (LRN mentioned some of the
difficulties).  Basically, the alternatives provide only the second
part mentioned above and some of the 3rd part.

Given these facts, not having a reasonable support for mingw32 sounds
unwise to me, to put it mildly.  At least until the alternatives catch
up with mingw32, that is, by providing a coherent set of tools and
support libraries like mingw32 does today.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]