[Top][All Lists]
[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