Advantages of MinGW (was: KDE Windows and releases)

[Kevin Kofler]

Some advantages MinGW has over VC++ which haven't been mentioned yet in the 
discussion:

* cross compiling:
I think there is a sizable chunk of developers who are potentially interested 
in supporting your platform, but are not running it themselves, at least not 
as their primary platform. (I am one of those: I run Fedora, but am 
interested in building Win32 binaries of at least one KDE-based application 
I'm developing. The KDE 4 port of that application is mostly working already, 
the Win32 port not so much, but it compiles.)
MinGW makes this fairly easy: unzip all the KDE MinGW binary ZIP files into a 
target prefix, set environment variables, use tweaked QMake specs:
http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/ktigcc/mingw/mkspecs/win32-cross-g++/
and there you go.
Cross-MinGW can be hosted on almost every imaginable platform, you can even 
cross-compile from a SPARC cluster or a PS3. For Fedora, people have made 
RPMs available, making it very easy to install.
Also, the next major version of CMake will support cross-compiling (supposedly 
without hacks like the ones I'm using for QMake), so it might become even 
easier to cross-compile KDE apps in the near future, given a compiler which 
supports it.
VC++, on the other hand, is bound to a single platform, at best it can be run 
in WINE (which is x86 only), and that might not work and/or break the EULA 
(and even if it happens to work now, there's no guarantee it will in the 
future).

* binary compatibility:
- Between versions: As long as you're using a GCC >= 3.4 (who still isn't?), 
there are no binary compatibility issues, GCC 3.4, 4.0, 4.1, 4.2 and 4.3 are 
all binary-compatible with each other for both C and C++.
- Between debug and release builds: Debugging builds are binary-compatible 
with builds without debugging information, which also eliminates 
the "redistributing debug DLLs forbidden by EULA" problem.

* compatibility with GCC code:
Several *nix programs only support GCC/g++ for building, with MinGW this is 
not a problem. Even if they need GCC 4.2, there's the GCC 4.2.1 tech preview 
which can be used and which is binary-compatible with GCC 3.4 (see above). 
And for most programs, 3.4 is actually good enough. For VC++, they need 
porting for an entirely different compiler.
From an application developer's point of view, there's no reason to port to 
different compilers when the same compiler (GCC) is available on all 
platforms they care about.


I also think the issue of Danny Smith's resignation has been way overblown:
* He released a GCC 4.2.1 port which should work just fine before leaving.
* There are hardly any MinGW-specific GCC patches left, the work has been 
merged into upstream GCC, where it will be maintained. Upstream GCC has 
declared MinGW an official secondary platform for GCC 4.3:
http://gcc.gnu.org/gcc-4.3/criteria.html
and I know some GCC-related companies such as CodeSourcery are interested in 
keeping MinGW support alive.

Danny played a very important role in getting MinGW to the point it's at now, 
but his resignation is not the end of the world.

Also compare with the other side: who's to guarantee that the Express Edition 
of VC++ will remain available and come with a EULA which is compatible with 
Free Software development? I think that despite Danny's resignation, MinGW is 
still the option with the less uncertain future.


For debugging: yes, Insight is available for MinGW, a binary can be downloaded 
from mingw.org (in the "GNU Source-Level Debugger" section under "Release 
Candidate: gdb-6.6", there's both insight and text-only gdb packages there). 
(It is also possible to debug MinGW binaries using a Cygwin build of Insight, 
but that should no longer be needed now that there's a native Insight.)

(For the cross-compiling folks: Don't expect that to work in WINE though. I 
wasn't able to do any debugging on executables running in WINE, neither with 
the native Fedora GDB nor with a MinGW one.)

        Kevin Kofler