Graham Percival <gra...@percival-music.ca> writes: > On Fri, Sep 23, 2011 at 03:03:46PM +0200, David Kastrup wrote: >> But we still need to find a solution where I have a chance of getting >> work done. > > dev/staging > > I just realized that I forgot to add this to the proposal. I'll > do that later tonight and send an updated version. > > Or better yet -- dev/lexer-fixes. Suppose that (almost) all your > work for the past 2 weeks went onto that branch. You think you're > done, so ask if it's ok to merge with master. James tests it, > sends you the output of "make doc" failing; you work a bit more, > maybe revert something, then announce that you think it's working > now. James tests again -- and since this is a major merge, he > tests a completely blank build dir, doing a full make doc, etc -- > and this time it passes. Merge happens, git master doens't break, > much celebrations by everybody. > >> Can we compromise on "make info" instead? > > No, because that doesn't compile any @lilypond examples. Besides, > "make info" is run during a normal "make" !
Wrong, and wrong. > There are ways of speeding up the whole "make doc" process... we can > probably cut the time in half by using a server, for example, since > that avoids loading the guile libraries for every single @lilypond. > OTOH, that would only work for hundreds of examples if we didn't have > any memory leaks. We could probably save another factor of two by > using guile 2.0. I think most of the time is spent in Ghostscript, anyway. If we could batch a lot of conversions into a single Ghostscript run, that would likely help a lot. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
