Advantages of MinGW (was: KDE Windows and releases)

[Jarosław Staniek]

Kevin Kofler said the following, On 2007-12-20 23:08:
> Some advantages MinGW has over VC++ which haven't been mentioned yet in the 
> discussion:

Kevin. Thanks for so great feedback.
Much of my thoughts on the topic are related to debugging tools rather than 
compiler itself.

> * 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.

This problem does not exist for dlls you compile. If you refer to what I've 
mentioned earlier: What I mean is redistributing msvc's debugging libs. You 
have to download them for yourself.

That said, I of course very much value the independency of release/debug 
builds of gcc.

> * 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.

Looking at large part of KDE code and its dependencies, I can say the 
differences are subtle for msvc 2k5, not even mentioning 2k8. I even support 
2k3 with no extreme efforts.

>>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.

The problem that I hope many of us are aware about: it'is not only about 
compiling. It's about cost of development when starting debugging session 
takes 300 MB minimum and who-knows-homw-many minutes. The hardware is 
expensive for many of us, and development time is even more.

> 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.

I am really looking forward to see _gdb_ project successful. Not only alive 
but competitive and kicking.

> 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.

This is why we (informally) do not have nor accepting features implemented by 
msvc-only code. At worst you have alternative lines of code or custome files 
in parallel with gcc-based, however most of the time it is windows and unix 
code, not related to selection of compilers.

Compare this to what you say in "Several *nix programs only support GCC/g++ 
for building". This is a no-go for any program that we plan to use on win32.

So we have a symmetry here:
- The possible lock-in at MS side are changes in EULA.
- The possible lock-in at mingw side is stagnation.

No single risk makes a given solution unusable on the next day. There is 
always some time to perform transition in either way. So IMHO it is important 
to have supporters of both build systems on the board.

> 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.)

It's a bit hard to compete with .NET/MONO for developers, having just tools 
like ddd or insight that provide Motif-like GUI.
As a former VB user [1] you know that young developer is usually not starting 
with hardcore tools :)

[1] http://www.tigen.org/kevin.kofler/pcprogs.htm

-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
  KDE Libraries for MS Windows (http://windows.kde.org)