> -----Original Message----- > From: Adrien Nader [mailto:adr...@notk.org] > Sent: Sunday, July 07, 2013 2:31 PM > To: Ruben Van Boxem > Cc: mingw-w64-public@lists.sourceforge.net > Subject: Re: [Mingw-w64-public] End of rubenvb builds > > Hi, > > Sorry for answering that late, I was away a bit and could catch up properly > only now. > > This email is unfortunately a bit long, sorry for that too. > > On Sun, Jun 23, 2013, Ruben Van Boxem wrote: > > Hi everyone, > > > > I have come to the conclusion that my MinGW-w64 builds bring too > > little to the table for me to continue maintaining them. > > > > I strongly encourage you to use the plethora of toolchains in a > > multitude of configurations available at mingw-builds. Comparing > > download numbers they have a much higher visibility, and e.g. their > > adoption by the Qt Project speaks of their quality. They have > > succeeded in doing what I missed when I decided to start building GCC, > > so my effort spent in doing that is now wasted. > > > > I may dabble into getting Clang 3.3 to work on Windows, perhaps even > > with > > libc++, but I am not promising anything. > > > > I'll still linger around here though, don't worry. > > This is sad to read. > As a packager I can only understand, in particular when you say that you will > probably continue but not try to be as up-to-date as you've been so far, which > you've done remarkably well. > > I believe no such work is ever "wasted work". Remember that a few years ago, > GCC for Windows meant mingw.org and lots of issues, starting with building > your own toolchain. The current ease of build proves how much work on this > has been done by everyone: building, helping, testing, fixing and so on.
I completely agree. Even while we in the qt-project ultimately went for mingw-builds, the personal builds by rubenv has always been my test whether a problem was in the mingw-builds package, or a more general upstream problem ... > If I've understood correctly, you're basing your decision partly on the > download stats from SF.net and the use of the mingw-builds toolchains by the > Qt project. > > Aaron Seigo had mentionned that the toolchain for the Qt project SDK had to > use Dwarf2 EH. He also had a whole liste of *hard* requirements (like having > multilib [ which I don't understand since QtCreator would hide it anyway ]). > This is a case where having more choice changes a lot of > things: most of us don't build multilib toolchains with dwarf2 eh. > This choice doesn't change anything to the quality of the toolchains and of > the > work behind them. The requirements you mentioned didn't came from Aaron Seigo, but were collected on the qt-developers mailing list and put down at http://qt-project.org/wiki/MinGW-64-bit , 'section Criteria for original decision on toolchain'. They weren't really *hard requirements*, but more like a wishlist to at least make a decision for one project. Anyway, as Alex as pointed out some of them are now obsolete, since we didn't go down the path of e.g. using one toolchain for 32 bit and 64 bit builds. Anyhow, the decision to go for mingw-builds was in the end not only based on technical criteria (besides some small mingw-make issue that was quickly resolved, rubenv's builds were working just fine for Qt IIRC), but also on soft facts like a personal build being by definition bound to one person. > [...] > > You usually don't hear about users and I'm under the impression that for > packagers it's even worse. However there are users; it might be difficult to > understand who they are, where they are and how they use the binaries but > they definitely exist. > > I'm not trying to change anyone's mind but I know this has been an open > question for a long time now and currently we're probably missing 99% of the > answer. While the question about what current users are using is already hard to answer, there's IMO a bigger one: What _potential_ users are there that aren't already using mingw-w64 :) I started looking into mingw-w64 maybe a year ago, only to find out that - there's no 'official' installer/ toolchain - there are a whole bunch of 'personal' builds & mingw-w64 derived projects - different projects provide a myriad of different gcc versions x architecture x exception handling mechanism x threading library combinations (and again, little hints on what is the 'recommended' configuration for most users). I can easily imagine a lot of potential users are being scared away by this overwhelming choice. Anyhow, this is going off topic here ... Kind regards Kai ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
