On 2013.06.19 18:09, Sean McBride wrote: >> I would have thought every one would >> run their compilers with (almost) every possible warning >> turned on
Not gonna happen as far as I'm concerned. Just for libusbx alone, I'm using 10 different compilers on _very_ regular basis (and I'm not even counting WinCE or older versions of MSVC in that lot, as I don't really bother with them any more). And for what is worth, the commit this fix comes on top of was compiled with at least 6 different compilers (Linux/gcc, VS2012, VS2012 code analysis, Clang/MinGW32, cygwin, OS X/XCode and I think I probably ran non Clang MinGW as well as WDK for good measure), and NONE of them reported a warning then. So, unless we change the default compilation options of libusbx to be as stringent as Ludovic's _custom_ options, I'm not planning to spend time babysitting compilers, some of which get reinstalled/updated on fairly regular basis (usually from scratch), and tweak their options to pick extra stuff. Either we decide that the default options we get for libusbx with the default compiler on the base platform are what we want to be warningless, and leave extra stuff to be picked on an ad-hoc basis, or we change our default options (which is something we did in the past for the MSVCs actually). Ludovic is simply using more stringent options than our defaults, and that's why he gets to pick all the extra stuff... > That said, it would be good if libusb adopted a more stringent development > process. ex: nightly buildbots, continuous buildbots, code review, unit > tests, etc. > > There are lots of tools to do this. With ctest/cdash we could have night > build results like this: > > <http://open.cdash.org/index.php?project=VTK> > > That show build errors, warnings, and test failures. > > And a tool like gerrit could be used to review and build patches before > integrating into master: > > <http://code.google.com/p/gerrit/> We talked about this. If you remember, I had a gerrit+Jenkins demo for libusbx setup about right around the time we forked. I even pointed to the test gerrit server that I had setup then (http://review.libusbx.org, which is no longer operational ATM). The issue is not that there aren't tools we could use, but that this stuff _does_ take time to configure and link together properly, and what's more, without a lot of tweaking (WDK in Wine? Cross XCode compilation on Linux) or funds to rent additional native servers to avoid cross compilation, we'll be leaving out major targets from our build tests. I still have properly setting up gerrit + Jenkins for libusbx and integrating it with github, then adding cross MinGW compilation somewhere on my TODO list. However, compared to other tasks, and when realistically estimating the return on investment for a project the size of libusbx, I just can't see myself giving this multi-week effort that high a priority right now. But of course, that doesn't mean that someone else can't go ahead and try their hands at it. ;) Regards, /Pete ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
