MinGW (Was: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets)

["Stephan T. Lavavej" <stl@caltech.edu>]

[DJ Delorie]
> some platforms are supported by groups outside of gcc development,
> who are in general happy with a target that doesn't happen to be
> useful as-is out of the gcc source tree, but would still be
> inconvenienced if that target were deprecated.

However, there are some platforms which are supported by non-gcc developers
and aren't useful as-is from FSF sources, yet the platform's users
desperately wish that gcc would work as-is.

I'm talking about MinGW, which - as far as I can tell - receives fairly
little attention from the gcc developers and the community in general,
despite being the *only* way to produce true Win32 executables that can be
licensed in any manner. From reading the MinGW and gcc mailing lists, I
believe that MinGW exists as a set of patches on a developer's hard drive to
the FSF sources. Thus, if I want to go and build MinGW, I can't, because I
don't have those patches. I have to wait until the MinGW developers release
a compatible set of patches and build the appropriate binaries.  For
example, I'm currently waiting for MinGW 3.3.

The message here is interesting:
http://sourceforge.net/mailarchive/forum.php?thread_id=2280276&forum_id=5119

[Danny R. Smith] 
> The idea is to get all the ming and cygwin local changes into 
> mainstream FSF CVS, so that there is no need for a branch.
> We are getting there.
> Mingw Java developers have been particularly active and the ReactOs
> people have also added a fair chunk.

>> I see these GCC .diff files for every MinGW GCC release.
>> Where are they coming from?
>> On a maintainer's hard drive, perhaps? =)

> Yes, mine, for now.
> But that is not satisfactory from my point of view either.  

>> What specifically keeps these patches from being committed?
 
> Time. Also, many heavy gcc developers have more importnat things to
> review than patches for an unsupported platform like mingw. 
> Cygwin, at least, is considered a secondary platform.
 
Given MinGW's importance as the only real way to run gcc on Windows, I don't
see why it's not even a secondary platform for gcc.

And even if MinGW doesn't become a secondary platform, it would be a great
help if the gcc developers could work on reviewing MinGW patches and getting
them hoovered into the mainstream FSF CVS.

I live in mortal fear that some day the MinGW developers will lose
interest/be hit by a truck/whatever, and gcc will suddenly become unusable
on Windows. Linux is great - I just put it on my second computer - but I
think it's important to keep gcc functional on Windows, if for nothing else
than to act as a gateway for new developers to get into the world of gcc.

Stephan T. Lavavej
http://stl.caltech.edu