lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Results of make check between 2.15.11-1 and 2.15.12-1


From: address@hidden
Subject: Re: Results of make check between 2.15.11-1 and 2.15.12-1
Date: Wed, 21 Sep 2011 07:25:09 +0200

On Sep 21, 2011, at 6:45 AM, Peekay Ex wrote:

> Hello,
> 
> This is really just an experiment to see if it worked as I wanted but
> also if it is something that is useful?
> 
> I couldn't workout the git command to rewind it all the way back to
> the 'merge branch release/unstable' for 2.15.11-1 so I used gitk and
> found that commit and simply right-click and selected 'reset master
> branch to here'. This seemed to work and git status showed I was 65
> commits behind and gitk looked like I would expect - with the top
> commit in the list the one back at 2.15.11-1.
> 
> At that point did a configure, make and a make test-baseline in my out
> of tree 'build' dir.
> 
> Then I did a simple 'git pull -r' and this put gitk all the way back
> to the last 'merge branch release/unstable' commit for 2.15.12-1 and
> then I ran (in my out of tree build dir)
> 
> rm mf/out/* ; make ; make check
> 
> and got the following output which I have zipped and attached here:
> 
> http://lilypond-stuff.1065243.n5.nabble.com/Make-check-for-diffs-between-2-15-11-1-and-2-15-12-1-td4825102.html
> 
> Unzip and point your browser at the index.html (it was the smallest
> file size - 1mb zipped, 6mb unzipped -  I could get and the quickest
> way I could think of to disseminate the information).
> 
> 1. Was this the correct work flow?
> 2. Is this useful at all?
> 

Hey James,

With respect to #2, it depends what you want to see.  make check only shows 
differences with respect to grobs whose extents and/or offsets have changed in 
LilyPond.  Their physical placement on the page may change without being 
registered and, inversely, a change may be registered without their moving.  My 
experience dictates is great for testing most changes to LilyPond, but bad for 
testing the effect of Y-extent / offset work on the visual output (remembers 
back to stem patch...shudders...).  In this case, a pixel by pixel comparison 
would be better.

So, in sum, my response is that it depends what you want.  As for your 
workflow, it makes sense - this will certainly get you baselines and 
comparisons in the places in time that you want them.

Cheers,
MS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]