http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/[email protected]/ 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
时间： 2024-09-28 18:51:28