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 > Either way, make things crystal clear. > > If an official toolchain is important to mingw-w64 and someone has the > passion and > time to take on the release mgr, the next step is rutheless simplification. > > For example, take Ruben's existing build infrastructure and morph a baseline > version > (non buildbot automated) into the mingw-w64 repo. As a strawman to kick > about, is the > following a good value-add first step? What else can be removed? > > 1) Build cross (Linux hosted) and non-cross (Windows hosted) on Linux as is > currently done. Add build-on-Windows support via MSYS/MSYS2 later. And > OS X hosted even later. > 2) Keep existing C, C++, Fortran, Obj-C, and Obj-C++ language support. > 3) Keep existing mingw32-make and python enabled GDB support. > 4) Provide single target 32 and 64-bit compilers for only GCC 4.8.1 > using Win32 threading with SEH or SJLJ. Other variants later. > 5) Release binaries to a new "Official Builds" folder > > Two concerns. First, who's going to take on the release mgr role, and second, > does > this add any real value above and beyond what mingwbuilds is already > providing? > > To help with the release mgr role, I strongly believe the toolchain build > process needs > to be trivial to perform so that the role is easy to transition in and out > of. No one is > going to step forward if the task is perceived as too onerous or requires a > long-term > committment. > > Thoughts? > > Jon > 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
