From: Ruben V. B. <van...@gm...> - 2013-06-23 13:15:36
|
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 |
From: K. F. <kfr...@gm...> - 2013-06-23 15:05:01
|
Hello Ruben! OOooohhh NOOOOOoooooOOOOO!!! On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem <van...@gm...> 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 |
From: Baruch B. <bmb...@gm...> - 2013-06-23 17:46:58
|
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 <kfr...@gm...> wrote: > Hello Ruben! > > OOooohhh NOOOOOoooooOOOOO!!! > > On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem > <van...@gm...> 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı |
From: LRN <lr...@gm...> - 2013-06-23 18:33:01
|
-----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----- |
From: Alexey P. <al...@gm...> - 2013-06-23 18:47:32
|
2013/6/23 LRN <lr...@gm...> > -----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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: Baruch B. <bmb...@gm...> - 2013-06-23 18:57:57
|
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 <bmb...@gm...>wrote: > 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 <kfr...@gm...> wrote: > >> Hello Ruben! >> >> OOooohhh NOOOOOoooooOOOOO!!! >> >> On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem >> <van...@gm...> 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 >> Min...@li... >> 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ʎ ɟı |
From: Ruben V. B. <van...@gm...> - 2013-06-23 19:00:44
|
2013/6/23 Baruch Burstein <bmb...@gm...> > 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 <bmb...@gm...>wrote: > >> 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 <kfr...@gm...> wrote: >> >>> Hello Ruben! >>> >>> OOooohhh NOOOOOoooooOOOOO!!! >>> >>> On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem >>> <van...@gm...> 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 >>> Min...@li... >>> 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
From: koala01 <ko...@fr...> - 2013-06-23 19:07:18
|
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 ) |
From: Alexey P. <al...@gm...> - 2013-06-23 19:07:36
|
2013/6/23 Baruch Burstein <bmb...@gm...> > 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 <bmb...@gm...>wrote: > >> 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 <kfr...@gm...> wrote: >> >>> Hello Ruben! >>> >>> OOooohhh NOOOOOoooooOOOOO!!! >>> >>> On Sun, Jun 23, 2013 at 9:15 AM, Ruben Van Boxem >>> <van...@gm...> 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 >>> Min...@li... >>> 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > |
From: Earnie B. <ea...@us...> - 2013-06-23 19:47:42
|
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 |
From: Baruch B. <bmb...@gm...> - 2013-06-23 19:52:17
|
On Sun, Jun 23, 2013 at 10:47 PM, Earnie Boyd <ea...@us...>wrote: > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı |
From: Ozkan S. <se...@gm...> - 2013-06-24 05:37:45
|
On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem <van...@gm...> 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. |
From: Ruben V. B. <van...@gm...> - 2013-06-24 07:13:53
|
2013/6/24 Ozkan Sezer <se...@gm...> > On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem > <van...@gm...> 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: NightStrike <nig...@gm...> - 2013-06-24 20:15:12
|
On Mon, Jun 24, 2013 at 1:37 AM, Ozkan Sezer <se...@gm...> wrote: > On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem > <van...@gm...> 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |
From: Kai T. <kti...@go...> - 2013-06-24 07:51:59
|
Hello Ruben, 2013/6/23 Ruben Van Boxem <van...@gm...>: > 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 |
From: Ozkan S. <se...@gm...> - 2013-06-24 08:22:25
|
On Mon, Jun 24, 2013 at 10:51 AM, Kai Tietz <kti...@go...> wrote: > Hello Ruben, > > 2013/6/23 Ruben Van Boxem <van...@gm...>: >> 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. |
From: Ruben V. B. <van...@gm...> - 2013-06-24 12:51:50
|
2013/6/24 Ozkan Sezer <se...@gm...> > On Mon, Jun 24, 2013 at 10:51 AM, Kai Tietz <kti...@go...> > wrote: > > Hello Ruben, > > > > 2013/6/23 Ruben Van Boxem <van...@gm...>: > >> 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: <fo...@sm...> - 2013-06-24 18:49:50
|
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 ? |
From: Jon <jon...@gm...> - 2013-06-25 15:07:22
|
> 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 Playing the non-PC devils advocate role... TL;DR - actively recruit a new mingw-w64 committer passionate about and responsible for regular, developer-friendly, mingw-w64 "official" binary toolchain releases. When I first became interested in the mingw-w64 project in the era before the fabulous rubenvb and mingwbuilds toolchain availability, I quickly became maddened with lack of "usable" windows-hosted automated builds. At that time, the windows-hosted automated builds were "unusable" to me because (a) they were only provided as cross-compilers (i686-w64-mingw32-gcc.exe) not the "native" compilers (gcc.exe) that developers building on windows hosts expect. (b) the downloads were monstrous because the relevant binaries had not been stripped as part of the build process. (c) the mingw automated builds were rarely up-to-date because the mingw buildbot was not being actively maintained and kept available. To add perceived "insult" to "injury", NightStrike and JonY appeared to be overly pedantic about cross-compilers and neither seemd to "get" why the above issues were important for developers simply wanting easy-to-acquire and easy-to-use mingw-w64 based toolchains for windows hosts. As such, my original perception of the mingw-w64 project was that mingw-w64 had too few committers to do a good job, had slid into the user unfriendly swamp, and two of the committers were too arrogant (or clueless) to recognize that change was needed in order to provide great toolchains to users. Frankly, I incorrectly came to the dangerous conclusion that mingw-w64 was a poorly run project. But as I paid more attention to the ML, my initial views (except the too few committers PoV) proved to be both naive and completely wrong; I was rewarded with an all expense paid trip to Dante's Fifth Circle sunny time share reserved for those who jump to conclusions too quickly. I often wonder how many newcomers to mingw-w64 have the same poor initial perspective of the project because of the lack of official, usable toolchains. And then came the rubenvb builds to save the day with Ruben annointed as the new toolchain release manager. Then came the mingwbuilds toolchains that provided even more choice and more goodies. The salad days. Life with mingw-w64 was good. But all things change, and we can't expect one to shackle themself to the often thankless boat anchor of perpetual maintenance. I believe mingw-w64 needs a minimalistic and flexible process and build tool that enable people to easily and gracefully enter and exit the role of official, user-friendly mingw-w64 toolchain release manager. Easy to say, but at the end of the day the key challenge will always be finding people with free time who are passionate about the role. I think Kai very wisely recognizes that mingw-w64 needs to do a better job of controlling its own destiny "I don't think we should let third-party ventures manage our work exclusive and not providing some base-knowledge and environment by ourself." Third party projects like mingwbuilds, tdm, and rubenvb will always exist with the goal of adding unique value. Some will come, and some will go. This is a Very Good Thing. 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 can be the foundation of a new official mingw-w64 toolchain release process. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://jonforums.github.io/ | http://thecodeshop.github.io/ twitter: @jonforums |
From: JonY <10...@gm...> - 2013-06-29 11:21:51
Attachments:
signature.asc
|
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. |
From: Adrien N. <ad...@no...> - 2013-07-07 12:31:28
|
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 |
From: Alexpux <al...@gm...> - 2013-07-07 16:06:58
|
-- 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > Regards, Alexey. |
From: Koehne K. <Kai...@di...> - 2013-07-10 06:58:57
|
> -----Original Message----- > From: Adrien Nader [mailto:ad...@no...] > Sent: Sunday, July 07, 2013 2:31 PM > To: Ruben Van Boxem > Cc: min...@li... > 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 |
From: Adrien N. <ad...@no...> - 2013-07-10 09:20:19
|
On Wed, Jul 10, 2013, Koehne Kai wrote: > > -----Original Message----- > > From: Adrien Nader [mailto:ad...@no...] > > Sent: Sunday, July 07, 2013 2:31 PM > > To: Ruben Van Boxem > > Cc: min...@li... > > 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 |
From: Martin M. <mi...@mo...> - 2013-07-10 08:03:17
|
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 |