On 2012.06.21 21:23, Sean McBride wrote: > It would be nice to have nightly builds of libusbx where the resulting > errors/warnings are gathered together for display.
I agree that it would be nice. However, since this is volunteer based, I'm doubtful whether we can gather the minimal amount of volunteers to make such a setup worth it. CMake and libusbx have quite the different numbers in terms of potential contributors and volunteers, and I don't really see ourselves having reached the critical mass required for the above, even more so as we're a recent fork. Realistically then, before we look into doing this, we should probably go around the horn and find out who would be willing to step in, and for which platform. It's fine and all to set up a BBQ with an open invitation, but it also doesn't hurt finding out how many people are going to come before you do that, to see if it's worth it. For instance, even if Orin has a copy of ICC, volunteering a server and time to ensure that libusbx gets built on regular basis with it is another story. I would say that, unless we have a prospect of getting a large enough base of volunteers, we may not want to jump too far ahead of ourselves, especially as we aren't getting that many reports of compilation breaking on non-common targets, that would warrant such a setup. Besides, we have concrete plans to set up a continuous integration and review server, to cater for at least one of Linux, MinGW, Clang, WDK and OS-X/BSD (if cross compilation can be set up for these last ones), and that won't rely on external volunteers. Moreover, as a continuous server, it will produce results for every single patch submitted, long before integration, thus with the right selection of targets, we should have some amount of confidence that libusbx compilation should be OK. Finally, because it aims at supporting so many platforms, the use of a continuous integration server for CMake is probably tricky (you can see HP-UX, IRIX, SunOS, AIX in there) which is probably why they had to call on an the greater community to help with the testing. And if you look more closely at how the whole thing actually works [1], it seems to be based on a series of more than 200 individual tests, that are part of CMake, rather than a simple report of compilation warnings. It must have taken them quite the effort to set it up, and, as much as I'd like to that, adding unit testing to libusbx is not where I would direct our time right now due to lack of resources. This is even more true as, unlike CMake, there's only so much we can do with unit testing in libusbx without hitting actual USB hardware and test USB devices. For the time being then, I'd wait and see what we can get with the planned continuous integration server. If after that, we still feel that it's not enough, we can try to looking into raising a volunteer user base with additional targets, and see if a CMake-like solution is achievable. Regards, /Pete [1] http://open.cdash.org/viewTest.php?onlypassed&buildid=2381596 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
