On Fri, Jul 01, 2011 at 11:26:04AM -0300, Han-Wen Nienhuys wrote: > On Thu, Jun 30, 2011 at 1:04 PM, Graham Percival > <gra...@percival-music.ca> wrote: > > Catching compilation (make and make doc) errors, and telling us > > exactly which commits occurred between the last successful build > > and the current failing attempt, would still save on average 5 > > hours of developer frustration each month. > > (oh, also running make distcheck) > > > > The sooner we know about breakage, the better. > > This was when gub was still in flux, so many compile problems then > were actually caused by gub changes.
IIRC we have not been able to compile git master 3 times in the past 2 months. Normal compile on linux, not GUB. Just plain old: git pull -r rm -rf build/ mkdir build cd build/ ../configure make make doc being broken. Yes, that *shouldn't* happen, but it does. We've generally discovered the breakage within 48 hours, but in one case (the pdf metadata stuff) it took a week. If we'd known that the pdf thing broke "make doc" within 24 hours, that would have narrowed the range of commits to examine -- I remember doing a git bisect to find where the docs broke (rebuilding from scratch every time!), because I didn't suspect the pdf stuff at all. There is no doubt in my mind that such a safety net would save us developer time and frustration. Such a script could be easily dumped into a cronjob; if all is well, it is silent; if any of those commands fails, it emails a warning to somebody (or a mailing list) giving the git commits between master and the previously-working build. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
