Re: [Mingw-w64-public] End of rubenvb builds
Hi, On Fri, Jul 12, 2013, Jon wrote: On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: 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. Allow me to mention yypkg again: http://yypkg.org/mingw-builds/ There are almost 70 packages, the website infrastructure is up, the package management is working and its infrastructure is up, the source-control infrastructure is also up. Everything is open and reproducible except for the download sources part for which I have a proper solution only since wednesday. The user aspect is documented and the packager one is partly-documented. If this gives a better idea of the current state, my TODO for this week-end and the next few days is: - update software to what has gotten in slackware-current - finish packaging sdl - package dbus - package ffmpeg - package gnustep which will help test the objc toolchain - patch bsdtar/libarchive to handle symlinks in packages more gracefully (symlinks if running with admin rights, junctions for dirs and copy for files otherwise; or something like that) (I'm trying to get sdl, dbus, ffmpeg and gnustep fairly quickly because they've been requested by people) PS: despite being named mingw-builds, this has nothing to do with the project on sf.net; mingw-builds is not a very specific name and I derived it from SlackBuilds: slackware's build scripts. (I plan on trying to find another name though) -- Adrien Nader -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
- package gnustep which will help test the objc toolchain Have you seen http://www.cocotron.org/ too? On Sat, Jul 13, 2013 at 12:22 PM, Adrien Nader adr...@notk.org wrote: Hi, On Fri, Jul 12, 2013, Jon wrote: On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: 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. Allow me to mention yypkg again: http://yypkg.org/mingw-builds/ There are almost 70 packages, the website infrastructure is up, the package management is working and its infrastructure is up, the source-control infrastructure is also up. Everything is open and reproducible except for the download sources part for which I have a proper solution only since wednesday. The user aspect is documented and the packager one is partly-documented. If this gives a better idea of the current state, my TODO for this week-end and the next few days is: - update software to what has gotten in slackware-current - finish packaging sdl - package dbus - package ffmpeg - package gnustep which will help test the objc toolchain - patch bsdtar/libarchive to handle symlinks in packages more gracefully (symlinks if running with admin rights, junctions for dirs and copy for files otherwise; or something like that) (I'm trying to get sdl, dbus, ffmpeg and gnustep fairly quickly because they've been requested by people) PS: despite being named mingw-builds, this has nothing to do with the project on sf.net; mingw-builds is not a very specific name and I derived it from SlackBuilds: slackware's build scripts. (I plan on trying to find another name though) -- Adrien Nader -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Sat, Jul 13, 2013, Ray Donnelly wrote: - package gnustep which will help test the objc toolchain Have you seen http://www.cocotron.org/ too? I hadn't. It's interesting but at the same time, I'm a bit worried because they mention patching ld and gcc. =/ In any case, I'll have a look at it. Thanks. Btw, I'm looking for software using Objc++, Java, Ada, Fortran. Even when the build doesn't fail, there's no guarantee the toolchains work: last time I tried, the gcj build succeeded but the final package was missing almost everything as far as I could tell. -- Adrien Nader -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Wed, Jul 10, 2013 at 5:30 PM, Jon jon.for...@gmail.com wrote: ...SNIP... 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 ;) Thoughts? Jon Speak-up-and-get-stuck-with-it ;) -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- 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=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Sat, Jul 13, 2013, Baruch Burstein wrote: On Wed, Jul 10, 2013 at 5:30 PM, Jon jon.for...@gmail.com wrote: 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 ;) Thoughts? It takes an awful lot of time. If you reach 100 packages (half of fedora or opensuse) and each package gets updated once every 6 months and it takes 30 minutes (when everything goes well), you're already looking at more than one hour per week. -- Adrien Nader -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
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
Re: [Mingw-w64-public] End of rubenvb builds
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.
Re: [Mingw-w64-public] End of rubenvb builds
-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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list
Re: [Mingw-w64-public] End of rubenvb builds
On 10.7.2013 8:58, Koehne Kai wrote: 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). (Disclaimer: Written not in an attempt to put you down, but in a hope such feedback is valuable for you.) A bit off-topic but I can sign that too. I was using mingw for a long time and when I felt the need to also build my projects for x64, it took me about _two_long_years_ until I finally switched from mingw (i.e., I was already quite close and the transition should be sooo easy), and when I finally did, it was only for x64 builds for another months. The reason for the long consideration was I was waiting for some official build/toolchain, thinking at that time you yourself (as a mingw-w64 team) do not consider it ready for general use until you have one... It is simply the matter of fact that newcomer does not know where to click to get basic info what he should download to get something standard when he has no special requirements. Instead you place him in front of too many (potentially difficult) questions like What is that exception type thing and what is the right for me? or What the hell is cross-compiling? and (arguably worse) Which developer of this project makes the best work in making the package? or (probably the worst) They cannot agree with one another so each of them need their own build? How can they work as a team? 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. Best regards, Martin -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Wed, Jul 10, 2013, Martin Mitáš wrote: On 10.7.2013 8:58, Koehne Kai wrote: 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). (Disclaimer: Written not in an attempt to put you down, but in a hope such feedback is valuable for you.) A bit off-topic but I can sign that too. I was using mingw for a long time and when I felt the need to also build my projects for x64, it took me about _two_long_years_ until I finally switched from mingw (i.e., I was already quite close and the transition should be sooo easy), and when I finally did, it was only for x64 builds for another months. The reason for the long consideration was I was waiting for some official build/toolchain, thinking at that time you yourself (as a mingw-w64 team) do not consider it ready for general use until you have one... It is simply the matter of fact that newcomer does not know where to click to get basic info what he should download to get something standard when he has no special requirements. Instead you place him in front of too many (potentially difficult) questions like What is that exception type thing and what is the right for me? or What the hell is cross-compiling? and (arguably worse) Which developer of this project makes the best work in making the package? or (probably the worst) They cannot agree with one another so each of them need their own build? How can they work as a team? 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. I find it quite funny that with mingw-w64 being much more open than mingw.org, there are more contributions from a more active community and that, in turn, this causes confusion. Years ago there were basically no toolchains. I think there were automated builds but they weren't always available. After discussions on IRC and mentions of my yypkg project, I was asked to provide such official builds and package management. Take into account the fact I was a student in a school system that leaves little free time, that the task was big (get the package manager working well everywhere, build the build infrastructure, build the toolchains, build all the packages with all their quirks...). Fast-forward today, yypkg is stable, works, there are quite a lot of packages, and there are many more people who provide toolchains. So, how can one of them be official? My work was supposed to be but that was years ago and I cannot suddenly appear and hide the other builds with mine. I built the current download page with that diversity in mind, trying to give a faire share of visibility to every project. In any case we now have the question: what would be official or even advised? -- Adrien Nader -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Wed, Jul 10, 2013, Koehne Kai wrote: -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. Thanks for the correction. It had been a fairly long time and I was under the impression that Aaron had added some of these requirements himself. In any case, it shows that some people value these some of these choices. Someone should confirm that but the Personal Builds are maybe a bit misnamed: they are space on sf.net for third-parties to upload their builds. Had the mingw-builds not created a separate project, the binaries would have been under personal builds. Maybe this should this be changed. -- Adrien Nader -- 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=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
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. 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. Or say The current situation is fine; mingw-w64 doesn't need an official 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 --- 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=48808831iu=/4140/ostg.clktrk
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. 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. As for the download stats, I've been trying to understand them for quite some time now without much luck. I was trying to see which impact the new download page would have. I haven't been able to see a difference. Mingw-builds has around 600 downloads per day, half of it seems to be metadata for the installer. I guess that the installer downloads the metadata file which then tells it which downloads are available (I might be completely wrong). This means that there are 300 new toolchain installations everyday. Close to 10k each month and that's around 30k for three month, until the next minor version comes out. In turn, this means there are at least 30k people installing toolchains themselves. I find this hard to believe: people are too lazy for that. We don't have much data for the downloads. When do they happen during the day, where from in the world, by which User Agent, ... ? For yypkg, I have a separate hosting and a webalizer on it. I lack details but I have some more information than what we get from sf.net. For the first 6 days of July, I got around 900 hits from a wget running on mingw32, i.e. the download client in yypkg and definitely not something else (bots, indexers, pidgins, ...). Due to the way yypkg works, this amounts to 2 to 3 downloads per day (I haven't advertized anything recently). Again, if we sum that over a few weeks, it's hundreds of users. I haven't heard *anything* from them. All I know is that they exist. It feels like looking for the Higgs Boson or black matter. 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. PS: adding something to the download page is available to any packager that provides the same amount of information as the other toolchains (copy-paste, replace with your own values); I don't think the page is currently crowded. I'll be spending some time on it again soon. -- Adrien Nader -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
-- Alexpux Отправлено с помощью Sparrow (http://www.sparrowmailapp.com/?sig) воскресенье, 7 июля 2013 г. в 16:31, Adrien Nader написал: 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. 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. Mingw-builds doesn't build multilib Dwarf toolchains. We build only Sjlj toolchains as multilib. And now Qt use our nomultilib toolchains. As for the download stats, I've been trying to understand them for quite some time now without much luck. I was trying to see which impact the new download page would have. I haven't been able to see a difference. Mingw-builds has around 600 downloads per day, half of it seems to be metadata for the installer. I guess that the installer downloads the metadata file which then tells it which downloads are available (I might be completely wrong). This means that there are 300 new toolchain installations everyday. Close to 10k each month and that's around 30k for three month, until the next minor version comes out. In turn, this means there are at least 30k people installing toolchains themselves. I find this hard to believe: people are too lazy for that. We don't have much data for the downloads. When do they happen during the day, where from in the world, by which User Agent, ... ? For yypkg, I have a separate hosting and a webalizer on it. I lack details but I have some more information than what we get from sf.net. For the first 6 days of July, I got around 900 hits from a wget running on mingw32, i.e. the download client in yypkg and definitely not something else (bots, indexers, pidgins, ...). Due to the way yypkg works, this amounts to 2 to 3 downloads per day (I haven't advertized anything recently). Again, if we sum that over a few weeks, it's hundreds of users. I haven't heard *anything* from them. All I know is that they exist. It feels like looking for the Higgs Boson or black matter. 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. PS: adding something to the download page is available to any packager that provides the same amount of information as the other toolchains (copy-paste, replace with your own values); I don't think the page is currently crowded. I'll be spending some time on it again soon. -- Adrien Nader -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net
Re: [Mingw-w64-public] End of rubenvb builds
On 6/25/2013 23:07, Jon wrote: But it's a Bad Thing that mingw-w64 doesn't have official, user-friendly toolchains, even if (for pragmatic reasons) only windows hosted and a linux host cross-compilers are provided. The current automated builds (apparently targeted to internal testing usage) are not a solution. I'm hoping that a version of Ruben's work at https://github.com/rubenvb/MinGW-w64-build-scripts Early on, Ozkan made the some binaries, they were good enough and given blessings as official builds. Soon after, Ruben made many newer builds, and they were good enough and given blessings as official builds. You can see how this goes, yes we need volunteers to do builds. You too can get some blessings by doing periodic releases AND staying in regular contact with mingw-w64 (eg lurking in #mingw-w64 irc) to report any usage issues. It doesn't have to be Windows builds, could be HPPA *nix or even NetBSD builds. signature.asc Description: OpenPGP digital signature -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
2013/6/24 Ozkan Sezer seze...@gmail.com On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. That's sad. I was using your builds from time to time, too. Perhaps you can document your build process in the project resources, e.g. place your scripts in the svn somewhere or something? I'll see to get a simple readme in the repository. Source downloads never got included in the build process (although they were a starting point in my now discontinued rewrite effort https://github.com/rubenvb/cross). If you want to get started right away, just download the full source package and replace the sources you want. Note there is no way to determine exactly what version of what package was used in the source tree, which is another shortcoming. ./buildall.sh builds all the toolchains, you can disable those you don't need or call the build*.sh scripts directly. Ruben 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. All the best, Ruben -- O.S. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
Hello Ruben, 2013/6/23 Ruben Van Boxem vanboxem.ru...@gmail.com: 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. All the best, Ruben First, I want to thank you for your hard work you've spent into providing your excellent toolchains over the last years. I am sad to hear that you discontinue it, but I am lucky to hear that you will be still reading this ML. Indeed it would be great, if you could put your build-experience into some documentation/build-scripts in our Wiki/repository. This information is for sure of much interest to our community. Any work on that is mostly appreachiated. That you think that mingw-builds is doing a better job as you did is at least for our community a least one good news ... nevertheless is mingw-builds a different venture, and I am not sure if we should drop that easy our own toolchains. I admit that as long as mingw-builds is well maintained, and build regular toolchains on sane-state of toolchain, it is ok, but as soon as this might not happen anymore we are getting in serious troubles. I don't think we should let third-party ventures manage our work exclusive and not providing some base-knowledge and environment by ourself. Thanks for your work and all the best, Kai -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Mon, Jun 24, 2013 at 10:51 AM, Kai Tietz ktiet...@googlemail.com wrote: Hello Ruben, 2013/6/23 Ruben Van Boxem vanboxem.ru...@gmail.com: 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. All the best, Ruben First, I want to thank you for your hard work you've spent into providing your excellent toolchains over the last years. I am sad to hear that you discontinue it, but I am lucky to hear that you will be still reading this ML. Indeed it would be great, if you could put your build-experience into some documentation/build-scripts in our Wiki/repository. This information is for sure of much interest to our community. Any work on that is mostly appreachiated. That you think that mingw-builds is doing a better job as you did is at least for our community a least one good news ... nevertheless is mingw-builds a different venture, and I am not sure if we should drop that easy our own toolchains. I admit that as long as mingw-builds is well maintained, and build regular toolchains on sane-state of toolchain, it is ok, but as soon as this might not happen anymore we are getting in serious troubles. I don't think we should let third-party ventures manage our work exclusive and not providing some base-knowledge and environment by ourself. Very well said, and I second this. I hope Ruben reconsiders. Thanks for your work and all the best, Kai -- O.S. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
2013/6/24 Ozkan Sezer seze...@gmail.com On Mon, Jun 24, 2013 at 10:51 AM, Kai Tietz ktiet...@googlemail.com wrote: Hello Ruben, 2013/6/23 Ruben Van Boxem vanboxem.ru...@gmail.com: 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. All the best, Ruben First, I want to thank you for your hard work you've spent into providing your excellent toolchains over the last years. I am sad to hear that you discontinue it, but I am lucky to hear that you will be still reading this ML. Indeed it would be great, if you could put your build-experience into some documentation/build-scripts in our Wiki/repository. This information is for sure of much interest to our community. Any work on that is mostly appreachiated. That you think that mingw-builds is doing a better job as you did is at least for our community a least one good news ... nevertheless is mingw-builds a different venture, and I am not sure if we should drop that easy our own toolchains. I admit that as long as mingw-builds is well maintained, and build regular toolchains on sane-state of toolchain, it is ok, but as soon as this might not happen anymore we are getting in serious troubles. I don't think we should let third-party ventures manage our work exclusive and not providing some base-knowledge and environment by ourself. I thought the Makefile under experimental was meant for that. Very well said, and I second this. I hope Ruben reconsiders. Let's say it like this: I'm whatever Gotham needs me to be [...] A hero. Not the hero we deserved but the hero we needed. Nothing less than a knight. Shining. A glued together quote to ease your minds. I'm just not committing to keep up to date. I'll probably be inexorably drawn into the cruel GNU build system world again. Cheers, Ruben Thanks for your work and all the best, Kai -- O.S. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
I wanted to compile GNUStep(objc) on windows because I would like to debug something and thus I prefer compile everything on windows and not cross-compile from linux. A few years ago I have built an environment(called MaxGW :-) consisting in the msys+mingw and their package manager mingw-get but used with packages compiled with mingw-w64 compiler. So I wanted to use this compiler(4.4.5) but the version is a bit old because it doesn't support objc 2.0 and was compiled from sezero package. So I have downloaded your package i686-w64-mingw32-gcc-4.7.4-release-win32_rubenvb but now I am realizing that there is no support for objc. Ok no problem I am a bit annoyed but it won't stop me because I was used to get sezero package and compile it myself but I couldn't find a corresponding source package on sourceforge. Do you provide it ? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Mon, Jun 24, 2013 at 1:37 AM, Ozkan Sezer seze...@gmail.com wrote: On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. That's sad. I was using your builds from time to time, too. You used to distribute your own builds, too :) Perhaps you can document your build process in the project resources, e.g. place your scripts in the svn somewhere or something? svn/experimental/buildsystem is a perfect place to upload scripts. 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. All the best, Ruben -- O.S. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] End of rubenvb builds
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. All the best, Ruben -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
Hello Ruben! OOooohhh NOoO!!! On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. Sad to see your builds depart! (But glad you're staying ...) Now, I'm sure them mingw-builds builds are fine, and such, but where's a fellow to go when he wants a nice, WACKY build? Hmm? You know, like a fine wine -- maybe a bit off the beaten path, quirky, even, but a worthy vintage, nonetheless. Thanks for all your work and all your builds. All the best, Ruben Happy Hacking! K. Frank -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
I used your builds too. I dont remember why, probably cause it was the first one I found that just worked. I'll give the mingw-builds a try. Thank you for your work. On Sun, Jun 23, 2013 at 6:04 PM, K. Frank kfrank2...@gmail.com wrote: Hello Ruben! OOooohhh NOoO!!! On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. Sad to see your builds depart! (But glad you're staying ...) Now, I'm sure them mingw-builds builds are fine, and such, but where's a fellow to go when he wants a nice, WACKY build? Hmm? You know, like a fine wine -- maybe a bit off the beaten path, quirky, even, but a worthy vintage, nonetheless. Thanks for all your work and all your builds. All the best, Ruben Happy Hacking! K. Frank -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.06.2013 17:15, 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. Since you brought this up, i have a question: how did you make your toolchains? And how are mingw-builds' toolchains made? Are they cross-compiled from *nix, or are existing W32 toolchains used to [cross-]compile them? - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRxz8hAAoJEOs4Jb6SI2CwhroH+QHQaSATuB07H8T2BZrkvAM6 n7hHY2FUjvAEY7eVeHMiLEflXe6VCIgW063zYAi2XShHMEQHdb7IIj5A6FEzuEKZ qGDAFEnsmKYa2CsvFxJvwGM1m+vNpcSq9JConmIFf/TiruEL1S5iPKANhpa9JbIb 16VcvJUbFUpH4CFpObWhvvpRSulgaIEifa5Pt5hTwfYLeDlHTU+9yEE/fLzMjh+y 5NY5j+WKTmFAK/dkEJebN2Q0Ko7MiBvYsSsVeUO7Rmmcbve+GTFaEi12VHFlK9ow M41iy5pknGhhPLeqyNNL4/ZDHHNgTK9dMwgYIiRRywMrIYeb/chHrdai4ABfSss= =/InE -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
2013/6/23 LRN lrn1...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.06.2013 17:15, 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. Since you brought this up, i have a question: how did you make your toolchains? And how are mingw-builds' toolchains made? Are they cross-compiled from *nix, or are existing W32 toolchains used to [cross-]compile them? Mingw-builds toolchains are builded in windows or wine under MSYS. As I know Ruben's toolchains are cross-compiled from Linux. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRxz8hAAoJEOs4Jb6SI2CwhroH+QHQaSATuB07H8T2BZrkvAM6 n7hHY2FUjvAEY7eVeHMiLEflXe6VCIgW063zYAi2XShHMEQHdb7IIj5A6FEzuEKZ qGDAFEnsmKYa2CsvFxJvwGM1m+vNpcSq9JConmIFf/TiruEL1S5iPKANhpa9JbIb 16VcvJUbFUpH4CFpObWhvvpRSulgaIEifa5Pt5hTwfYLeDlHTU+9yEE/fLzMjh+y 5NY5j+WKTmFAK/dkEJebN2Q0Ko7MiBvYsSsVeUO7Rmmcbve+GTFaEi12VHFlK9ow M41iy5pknGhhPLeqyNNL4/ZDHHNgTK9dMwgYIiRRywMrIYeb/chHrdai4ABfSss= =/InE -END PGP SIGNATURE- -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
And of course, as expected. I just went to try the mingw-builds, and downloaded their recommended installer (the download button on the front page), and when tried to run it, it didn't work (couldn't download repository.txt or some such). We really need a build that just works. (I know, your builds didn't have any installer, and if I am willing to live without the installer for your builds, I can just directly download the appropriate package from the mingw-builds site and unpack it, but there is something anoying about trying the recommended way of doing things and not getting it to work that kind of pushes me away from the whole thing) --- END OF RANT On Sun, Jun 23, 2013 at 8:46 PM, Baruch Burstein bmburst...@gmail.comwrote: I used your builds too. I dont remember why, probably cause it was the first one I found that just worked. I'll give the mingw-builds a try. Thank you for your work. On Sun, Jun 23, 2013 at 6:04 PM, K. Frank kfrank2...@gmail.com wrote: Hello Ruben! OOooohhh NOoO!!! On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. Sad to see your builds depart! (But glad you're staying ...) Now, I'm sure them mingw-builds builds are fine, and such, but where's a fellow to go when he wants a nice, WACKY build? Hmm? You know, like a fine wine -- maybe a bit off the beaten path, quirky, even, but a worthy vintage, nonetheless. Thanks for all your work and all your builds. All the best, Ruben Happy Hacking! K. Frank -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
2013/6/23 Baruch Burstein bmburst...@gmail.com And of course, as expected. I just went to try the mingw-builds, and downloaded their recommended installer (the download button on the front page), and when tried to run it, it didn't work (couldn't download repository.txt or some such). We really need a build that just works. (I know, your builds didn't have any installer, and if I am willing to live without the installer for your builds, I can just directly download the appropriate package from the mingw-builds site and unpack it, but there is something anoying about trying the recommended way of doing things and not getting it to work that kind of pushes me away from the whole thing) I didn't even know they had an installer. Just download the zips: http://sourceforge.net/projects/mingwbuilds/files/?source=navbar And be done with it. I tend to avoid installers when it comes to development related things. Ruben --- END OF RANT On Sun, Jun 23, 2013 at 8:46 PM, Baruch Burstein bmburst...@gmail.comwrote: I used your builds too. I dont remember why, probably cause it was the first one I found that just worked. I'll give the mingw-builds a try. Thank you for your work. On Sun, Jun 23, 2013 at 6:04 PM, K. Frank kfrank2...@gmail.com wrote: Hello Ruben! OOooohhh NOoO!!! On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. Sad to see your builds depart! (But glad you're staying ...) Now, I'm sure them mingw-builds builds are fine, and such, but where's a fellow to go when he wants a nice, WACKY build? Hmm? You know, like a fine wine -- maybe a bit off the beaten path, quirky, even, but a worthy vintage, nonetheless. Thanks for all your work and all your builds. All the best, Ruben Happy Hacking! K. Frank -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
Le 23/06/2013 21:00, Ruben Van Boxem a écrit : I didn't even know they had an installer. Just download the zips: http://sourceforge.net/projects/mingwbuilds/files/?source=navbar And be done with it. I tend to avoid installers when it comes to development related things. Ruben just take a look between menu buttons and the home text. You'll find a text as Looking for the latest version? *Download mingw-builds-install.exe (170.0 kB) http://sourceforge.net/projects/mingwbuilds/files/latest/download?source=files *which point to the installer ( http://sourceforge.net/projects/mingwbuilds/files/latest/download?source=files ) -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
2013/6/23 Baruch Burstein bmburst...@gmail.com And of course, as expected. I just went to try the mingw-builds, and downloaded their recommended installer (the download button on the front page), and when tried to run it, it didn't work (couldn't download repository.txt or some such). We really need a build that just works. (I know, your builds didn't have any installer, and if I am willing to live without the installer for your builds, I can just directly download the appropriate package from the mingw-builds site and unpack it, but there is something anoying about trying the recommended way of doing things and not getting it to work that kind of pushes me away from the whole thing) --- END OF RANT Sometimes SF.net has problems with downloading files... On Sun, Jun 23, 2013 at 8:46 PM, Baruch Burstein bmburst...@gmail.comwrote: I used your builds too. I dont remember why, probably cause it was the first one I found that just worked. I'll give the mingw-builds a try. Thank you for your work. On Sun, Jun 23, 2013 at 6:04 PM, K. Frank kfrank2...@gmail.com wrote: Hello Ruben! OOooohhh NOoO!!! On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. Sad to see your builds depart! (But glad you're staying ...) Now, I'm sure them mingw-builds builds are fine, and such, but where's a fellow to go when he wants a nice, WACKY build? Hmm? You know, like a fine wine -- maybe a bit off the beaten path, quirky, even, but a worthy vintage, nonetheless. Thanks for all your work and all your builds. All the best, Ruben Happy Hacking! K. Frank -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Sun, Jun 23, 2013 at 3:07 PM, Alexey Pavlov wrote: 2013/6/23 Baruch Burstein And of course, as expected. I just went to try the mingw-builds, and downloaded their recommended installer (the download button on the front page), and when tried to run it, it didn't work (couldn't download repository.txt or some such). We really need a build that just works. (I know, your builds didn't have any installer, and if I am willing to live without the installer for your builds, I can just directly download the appropriate package from the mingw-builds site and unpack it, but there is something anoying about trying the recommended way of doing things and not getting it to work that kind of pushes me away from the whole thing) --- END OF RANT Sometimes SF.net has problems with downloading files... Exactly, especially recently since all projects have been moved to their new Allura systems. And sometimes you'll get a partial download. Try differing mirrors to determine if it helps. -- Earnie -- https://sites.google.com/site/earnieboyd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Sun, Jun 23, 2013 at 10:47 PM, Earnie Boyd ear...@users.sourceforge.netwrote: On Sun, Jun 23, 2013 at 3:07 PM, Alexey Pavlov wrote: 2013/6/23 Baruch Burstein And of course, as expected. I just went to try the mingw-builds, and downloaded their recommended installer (the download button on the front page), and when tried to run it, it didn't work (couldn't download repository.txt or some such). We really need a build that just works. (I know, your builds didn't have any installer, and if I am willing to live without the installer for your builds, I can just directly download the appropriate package from the mingw-builds site and unpack it, but there is something anoying about trying the recommended way of doing things and not getting it to work that kind of pushes me away from the whole thing) --- END OF RANT Sometimes SF.net has problems with downloading files... Exactly, especially recently since all projects have been moved to their new Allura systems. And sometimes you'll get a partial download. Try differing mirrors to determine if it helps. The installer does not ask for a mirror. -- Earnie -- https://sites.google.com/site/earnieboyd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem vanboxem.ru...@gmail.com 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. That's sad. I was using your builds from time to time, too. Perhaps you can document your build process in the project resources, e.g. place your scripts in the svn somewhere or something? 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. All the best, Ruben -- O.S. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
