<p>Op 3 aug. 2011 21:28 schreef "Sandeep Patel" <<a href="mailto:deeppatel1987@gmail.com">deeppatel1987@gmail.com</a>> het volgende:<br>
><br>
> Buildbots that test MinGW in one way or another:<br>
><br>
> <a href="http://google1.osuosl.org:8011/builders/llvm-gcc-native-mingw32">http://google1.osuosl.org:8011/builders/llvm-gcc-native-mingw32</a><br>
> <a href="http://google1.osuosl.org:8011/builders/llvm-gcc-native-mingw32-win7">http://google1.osuosl.org:8011/builders/llvm-gcc-native-mingw32-win7</a><br>
> <a href="http://google1.osuosl.org:8011/builders/llvm-gcc-mingw32-cross-arm-linux-gnueabi-hard-float">http://google1.osuosl.org:8011/builders/llvm-gcc-mingw32-cross-arm-linux-gnueabi-hard-float</a><br>
> <a href="http://google1.osuosl.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi">http://google1.osuosl.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi</a><br>
> <a href="http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-self-mingw32">http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-self-mingw32</a><br>
> <a href="http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-cross-mingw32">http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-cross-mingw32</a><br>
><br>
> What additional coverage would you like to see?</p>
<p>Yes, i noticed these; they test the llvm/clang build, but don't touch real world projects. This is important for a compiler, as some (most) changes won't directly affect the internal clang build/test process. My first email on the subject suggested some external common libraries with extensive test suites that could help a build bot find more exotic bugs.</p>

<p>Completely orthogonal to this, is a test for MinGW-w64, including 64-bit. Or even a visual studio test bot. All these would be nice to have. I understand the later might be harder (visual studio won't run in Unix environments...)</p>

<p>Thanks for the interest!</p>
<p>Ruben</p>
<p>><br>
> deep<br>
><br>
> On Mon, Aug 1, 2011 at 3:35 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br>
> ><br>
> > On Aug 1, 2011, at 8:20 AM, Ruben Van Boxem wrote:<br>
> ><br>
> >> 2011/8/1 Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>>:<br>
> >>><br>
> >>> On Aug 1, 2011, at 4:37 AM, Ruben Van Boxem wrote:<br>
> >>>> Concretely, I suggest a larger table with colors like the C++0x table,<br>
> >>>> with red = doesn't build, orange/yellow: builds, but tests fail due to<br>
> >>>> a problem in clang (which also means that the tests pass for GCC), and<br>
> >>>> green is that it builds and all tests pass without a hitch. Links<br>
> >>>> could be placed to bug reports about the issue, where detailed<br>
> >>>> information for interested developers could be placed.<br>
> >>>><br>
> >>>> The libraries I suggest that should be used as a "quality mark" are<br>
> >>>> (more are of course welcome!):<br>
> >>>><br>
> >>>> Qt: Huge GUI and core library framework. High quality code that is<br>
> >>>> extremely cross-platform. Has an internal test suite, but I haven't<br>
> >>>> yet figured out how to run it (I can't as the build fails on Windows)<br>
> >>>> wxWidgets: that other tadbit less huge GUI and core framework. Also<br>
> >>>> high quality code.<br>
> >>>> GSL: GNU Scientific library: comprehensive test suite.<br>
> >>>> FFTW: Known around the world, comprehensive test suite<br>
> >>>> Eigen: idem<br>
> >>>> Flac: idem<br>
> >>>> GMP, MPFR, MPC, PPL, CLooG: very fragile and comprehensive libraries.<br>
> >>>> Also all feature a nice test suite.<br>
> >>>> Perhaps all the open source graphics libraries (Tiff, png, jpeg, turbojpeg...)<br>
> >>>><br>
> >>>> What do you guys think? I do not know HTML, so the table editing would<br>
> >>>> have to be almost trivial for me to get it done :s. I can test<br>
> >>>> regularly and see if certain revisions fix the problem (on Windows).<br>
> >>><br>
> >>><br>
> >>> The problem with putting these tables up on a web page is that they get out of date very, very quickly. So, for them to be useful, they really need to be updated automatically. Then best way to do that, in my mind, would be to set up a buildbot that tests these projects. Bring the buildbot online when one of the projects starts working on that platform, and keep it running: the buildbot will tell us when things are broken, so we won't regress.<br>

> >><br>
> >> I understand, that's probably the reason it was removed in the first<br>
> >> place. The buildbot is an awesome idea, and LLVM/Clang wouldn't be the<br>
> >> first Apple sponsored project to have every commit go through a<br>
> >> build+test project (yes, I'm looking at you, WebKit). This kind of<br>
> >> large-scale infrastructure would have to be LLVM-wide to be effective,<br>
> >> as Clang and LLVM development are intertwined.<br>
> >><br>
> >> Are there any plans for such a buildbot and continuous testing infrastructure?<br>
> ><br>
> > Well, there's already<br>
> ><br>
> >        <a href="http://google1.osuosl.org:8011/">http://google1.osuosl.org:8011/</a><br>
> ><br>
> > and there are plans to get a much-expanded, much-improved version online in the near future. However, I don't know if anyone has plans to actually bring buildbots online for MinGW specifically, or introduce your suggested libraries into the mix.<br>

> ><br>
> >        - Doug<br>
> > _______________________________________________<br>
> > cfe-dev mailing list<br>
> > <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
> ><br>
</p>