Comparison of Win-Builds and WSYS2 on MinGW_w64

转自：http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/20150529070201.GA8281@notk.org/

Hi,

I am the main developer of Win-builds.

NB 1: I slept 4 hours
NB 2: I'll be away from keyboard, maybe for 24 hours

On Fri, May 29, 2015, Prasanna V. Loganathar wrote:
> Hi, 
> 
> I had been using the builds as a part of MSYS2 for a while now, and I
> believe this is the most robust and easiest way to install mingw-w64. Also,
> due to the inherent nature of the system, it also provides the most
> up-to-date builds on par with the Linux builds. 
> 
> The build I see on winbuilds is actually older than the one on MSYS2. I'm
> just wondering if it would be in the best interests of the entire community
> that MSYS2 be promoted as the preferred build from the website instead of
> winbuilds. While win-builds seem to provide a GUI and switchable toolchain,
> MSYS2 just feels a lot more robust with, especially pacman. Pacman
> integration at its crux, seems to be the most brilliant package management
> strategy for windows, so far.  
> 

First of all, talking only about gcc, mingw-w64 and binutils is very
restrictive. All the builds have much more than that.

It's fairly common to hear that toolchain X is older than toolchain Y.
But first of all, does this even matter? Is there a bug with the GCC 4.8
branch? Or with mingw-w64 3.x? Or something else?
If so, it should be fixed upstream and backported to the
currently-supported releases. As far as I can tell, things work fairly
well that way in practice.

MSYS2 is a rolling-release distribution. It will most certainly be more
up-to-date that win-builds but that's by design: both from msys2 and
win-builds.
Win-builds has full releases which are maintained. This means two
things: once you start using one version, you don't get major software
updates all of the time and can therefore get security and stability
updates for a while without having to update between major software
releases. The drawback is that updates are filtered and the larger they
are, the less likely they are to be applied.

When the currently-visible version of win-builds was made, GCC 4.9 was
already available. It was a deliberate decision to /not/ use it because
at that time, while not providing anything new that was usable, it had
serious stability issues.

By the way, GCC 5 does not have the same ABI as GCC 4.x for C++.
Therefore every C++ code will need a rebuild. It's a major change and
not necessarily something you want to see happen while you're
developing your code.

The wish for more updates has been acknowledged in win-builds: there is
now a "next" repository which is the current development status. It
should be at least as stable as what can be obtained through msys2 but
it's not a win-builds release with a version: it's the in-progress repo.

> By the looks of the websites, I believe I can assume that the maintainers of
> winbuilds and mingw-w64 are the same or perhaps at the least linked.

As I said, I am the main maintainer of win-builds. I am also the main
maintainer of the website but it's been free for many many people to
edit for quite some time (and even more now that it's actually a wiki).

For the little story, for the look part: I migrated win-builds.org from
self-made html/php to dokuwiki fairly quickly, got positive feedback
except for the theme which looked too much like a wiki, found another
one which pleased pretty much everyone.
Then I tried to make yet another minor update to the old website and
that was really too much suffering. Considering dokuwiki had been very
easy to set up a few weeks earlier for win-builds.org, I made a
proof-of-concept port for the website. Ate my week-end but worked.
Waited a bit to get some feedback and then switched the websites.

> But I
> would very much like to think that it would be better to focus the efforts
> on one if so, and perhaps may be even implement winbuilds over msys2's
> excellent convergence work. But until then, I think it may make a lot more
> sense to converge with MSYS2 for official sources, rather than use the
> winbuilds system. Windows GCC (MinGW) builds of libraries have historically
> been a pain, because of the numerous different possible configuration the
> default build could have had, and due to the nature of the various sources,
> and none to be so-called "official" (or at-least a de-facto standard).
> Having winbuilds, and MSYS2 could again promote such problems, while
> converging them could very easily become the de-facto standard.

Win-builds has other differences compared to msys2. One of them is that
it's pretty much platform-agnostic. It started as a cross-compilation
years ago (way way earlier than msys2) and the fact that it has a
toolchain that runs on windows is a very small part of the whole
project.

Win-builds supports very well the scenario where you build from a sane
operating system (say Linux) and want to have windows binaries: it makes
it easy to build on your preferred system and deploy on Windows. The
build times are also much shorter that way. It has been thought as a way
to simplify the build of free software for Windows and therefore improve
the quality of Windows support in free software while also requiring less
time.

It is also going to support Mac OS X and *BSD systems soon. Actually it
should already pretty much work and if Apple wasn't the crap company it
is (want to test your software on their operating system? buy expensive
hardware from them), it would already be finished.

Even on Windows it comes with very few strings attached. I've tested
with several IDEs and was able to setup everything easily. The only two
exceptions were Codelite (the issue really looked like a bug in
codelite) and iirc Netbeans (it required an msys-style installation:
posix makefiles and shell).

What bothers me with the MSYS2 crowd on this mailing-list is their bias.
It's a very natural one and I'm not blaming anyone at all. My point is
that I could say that Linux is the OS on which people build and use
mingw-w64, and most here would probably agree. However the reality is
that this mailing-list and the people directly involved in the project
are not at all representative of the users. We're not even the 1%, we're
closer to the 0.1%.

Half of the proponents of msys2 seem to have used Arch Linux first. I
doubt this is representative of the actual users. Most probably use IDEs
and would never want to abandon them. Requiring command-line, even for
short amounts of time, is the same story.
(by the way: please don't think about masquerading anything with an
msys-style behaviour as a typical windows executable, it'd be a
dis-service to users who would probably get difficult-to-understand
bugs)

Long mail already so I'll try to summarize without forgetting too many
things:
- platform support is different and support for compiling on windows is
  a minor and natural cost (deploying GCC's .dll files was the first
  reason)
- the vast majority of people does not want to deal with something
  command-line and/or posix/linux
- I'm not saying msys2 is bad
- approach to packaging, distribution and maintenance are different;
  doesn't make one better but for sure, there are people to prefer each
  one over the other


Regards,
Adrien Nader
http://win-builds.org