On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz <ktiet...@googlemail.com> wrote:
> 2013/7/10 Jon <jon.for...@gmail.com>: > >> > > 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). > >> > > > >> > ...SNIP... > >> > > >> > I do not say that not offering any option is the right way. But there > >> > should be something what is "default". And the "default" should be > >> > offered as that. It should be much more visible, and available in a > >> > click or two from the homepage. And last but not least, the "default" > >> > should not be tagged as a personal build. You should minimize the number > >> > of question he needs to answer to get "just some compiler to build my > >> > program with". > >> > > >> > To summarize, IMO, mingw-w64, although technically as good as it is, > >> > emits bad signals to newcomers. Unfortunately, it has always been > >> > repelling for new users and, I believe, it is also the reason why > >> > mingw-builds (although also not ideal for sure) succeeded so easily. It > >> > simply filled the gap in the demand, which you never attempted to fill. > >> > >> I believe everyone will concur. > >> > >> ...SNIP... > >> > >> In any case we now have the question: what would be official or even > >> advised? > > > > This is not a technical issue. It's primarily a mingw-w64 project > > leadership and > > simplification challenge. > > > > It's not helpful that neither Kai nor JonY has definitively weighed in on > > whether > > an official mingw-w64 default toolchain makes sense. Actually, that's not > > true. > > Awhile back Kai was very involved with announcing Ruben as the new build > > release > > mgr. I interpreted Kai's actions to mean that he felt mingw-w64 needed a > > maintained, > > official, easy-to-use default toolchain in addition to the automated > > testing builds. > > Well, I assumed I was clear about that already. IMO it is absolutely > necessary that we (mingw-w64) are providing an official > toolchain-version, which we are recommenting. > To be clear here, those toolchain-releases aren't mingw-w64 releases. > The mingw-w64 releaes are just releases of our repository, not that of > combinations with other ventures. > And exactly this might be confusing here for some people. A pre-build > toolchain release is always just "one" variant of a combination using > our stuff with other ventures. That makes such releases so hard to be > marked as "recommented". > Nevertheless I agree completely that we have to provide such pre-build > toolchains, so that users have an easier access to our work. > > > > But "interpreting" or "implying" or "inferring" is not useful. Explicit > > clarification > > from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why > > this hasn't > > happened is that both already have too much on their plate and don't want > > to set the > > expectation that either will be responsible for implementing and > > maintaining an official > > toolchain like JonY appears (aweome) to be doing at > > http://cygwin.mirrors.pair.com/release/gcc4/ > > The old speak-up-and-get-stuck-with-it paradox ;) > > > > That's OK, and is why I believe the first step needs to be Kai/JonY saying > > (a) "The > > mingw-w64 project needs an official, easy-to-use toolchain", (b) "Neither > > of us > > have the bandwidth to implement/maintain it", and (c) "We're actively > > looking for > > a new committer to take on this role. If this is going to happen and be > > sustainable, > > we need your help." > > a) yes, b) yes (we need people in charge for that and doing this > reliable), c) yes, we are actual in discussion with mingw-builds > venture to go together (and/or co-operate more closely). > > > Or say "The current situation is fine; mingw-w64 doesn't need an official > > toolchain." > > No, we should provide Windows native pre-build toolchain Fantastic. These days I don't get to contribute to OSS as much as I'd like, but if it would be useful, I'll carve out time to test/provide feedback on any toolchain build tool you and the mingw-builds team come up with. I'm fixated by easy-to-use port-like build automation tools that do the typical cycle of download -> verify -> patch -> configure -> build -> stage -> package and am continuously toying with one of my own little monsters for building common libs with mingw-w64: https://github.com/jonforums/buildlets So, I'm curious on what you guys are building and would like to help, even if it's just easy-of-use testing of the build tool. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://jonforums.github.io/ | http://thecodeshop.github.io/ twitter: @jonforums ------------------------------------------------------------------------------ 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
