Neil Puttock: > On 15 May 2010 14:37, Karl Hammar <k...@aspodata.se> wrote: > > git-pull > > wget http://codereview.appspot.com/download/issue931041_1.diff > > patch -p1 < issue931041_1.diff --dry-run > > patch -p1 < issue931041_1.diff > > make > log 2>&1; make test-redo >> log 2>&1 > > I very rarely use `make test-redo'.
The difference between test-redo and check is small:
$ grep -A 6 ^test-redo: GNUmakefile
test-redo:
for a in `cat $(RESULT_DIR)/changed.txt` ; do \
echo removing $$a* ; \
rm -f $$a* ;\
done
$(MAKE) check
$ grep RESULT_DIR GNUmakefile | head -1
RESULT_DIR=$(top-build-dir)/out/test-results
$ cat out/test-results/changed.txt; echo # missing final newline
input/regression/out-test//test-output-distance
input/regression/out-test//rest-collision-beam-note
input/regression/out-test//tree
$
Does it matter, if not, why is in the contributor manual ?
> I basically do what Carl outlined in the other thread:
>
> make test-baseline
>
> git apply issue931041_1.diff
>
> make check
The contributor manual says (3.6.3.1):
* Initial test:
make [-jX]
make test-baseline
make [-jX CPU_COUNT=X] check
* Edit/compile/test cycle:
_## edit source files, then..._
make clean _## only if needed (see below)_
make [-jX] _## only if needed (see below)_
make test-redo _## redo files differing from baseline_
make [-jX CPU_COUNT=X] check _## CPU_COUNT here?_
* Reset:
make test-clean
It has an "make check" after the test-baseline which you don't have, is
it redundant?
git-apply and patch -p1 produces the same result, so that is not the
cause of our different output:
$ cd ..
$ cp -a lilypond/ lilypond.b
$ cd lilypond.b/
$ git-apply -v issue931041_1.diff
Applied patch lily/bar-line.cc cleanly.
Applied patch lily/include/bar-line.hh cleanly.
Applied patch lily/include/note-spacing.hh cleanly.
Applied patch lily/include/paper-column.hh cleanly.
Applied patch lily/multi-measure-rest.cc cleanly.
Applied patch lily/note-spacing.cc cleanly.
Applied patch lily/paper-column.cc cleanly.
Applied patch scm/define-grob-properties.scm cleanly.
Applied patch scm/define-grobs.scm cleanly.
$ cd ../lilypond
$ patch -p1 < issue931041_1.diff
patching file lily/bar-line.cc
patching file lily/include/bar-line.hh
patching file lily/include/note-spacing.hh
patching file lily/include/paper-column.hh
patching file lily/multi-measure-rest.cc
patching file lily/note-spacing.cc
patching file lily/paper-column.cc
patching file scm/define-grob-properties.scm
patching file scm/define-grobs.scm
$ cd ..
$ diff -Naur lilypond*
$
> > Also, it would be much easier to look throuht the patch if it did not
> > contain so many whitespace changes. In the first 100lines, I see:
>
> Why would you want to look at the bare diff?
Isn't the diff a complete statement of what you want to change?
Also you *did* cite the diff.
> The whole point of
> uploading the patchset to Rietveld is to make it easier to see the
> changes in each file.
Well, it might help someone else, but not me -- I have mail and git.
Putting things on web sites and getting things from them makes it take
more time.
***
If I take it from the beginning:
$ git-log | head -1
commit 22d889f4d27469864c31db81445e9de49774ae23
$ git-status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# issue1195044_1_2.diff
# issue1195044_1_3.diff
# issue931041_1.diff
# log
nothing added to commit but untracked files present (use "git add" to track)
$ make clean > /dev/null 2>/dev/null
$ make > log 2>&1
$ make test-baseline > log1 2>&1
Processing ./snippet-map-1678077630
...
Processing 41/lily-67666737
Failed files: ()
$ make check > log2 2>&1
Processing ./snippet-map-1678077630
...
Processing 90/lily-015675ea
Failed files: ()
$ patch -p1 < issue931041_1.diff
$ make > log3 2>&1
$ make test-redo > log4 2>&1
Processing ./snippet-map--1837524129
...
Failed files: ()
$ fgrep '<img src="input/regression/out-test/' out/test-results/index.html |
grep -v test-output-distance.compare.jpeg
<img src="input/regression/out-test//rest-collision-beam-note.compare.jpeg"
style="border-style: none; max-width: 500px;">
$ # above file attached
$ make check > log5 2>&1
Processing ./snippet-map-170730255
...
Failed files: ()
$ # the same output is produced
$ ls -1 input/regression/out-test/multi-measure-rest-multi-staff-center*
input/regression/out-test/multi-measure-rest-multi-staff-center-1.eps
input/regression/out-test/multi-measure-rest-multi-staff-center-1.signature
input/regression/out-test/multi-measure-rest-multi-staff-center-systems.count
input/regression/out-test/multi-measure-rest-multi-staff-center-systems.tex
input/regression/out-test/multi-measure-rest-multi-staff-center-systems.texi
input/regression/out-test/multi-measure-rest-multi-staff-center.eps
input/regression/out-test/multi-measure-rest-multi-staff-center.log
input/regression/out-test/multi-measure-rest-multi-staff-center.ly
input/regression/out-test/multi-measure-rest-multi-staff-center.profile
input/regression/out-test/multi-measure-rest-multi-staff-center.texidoc
input/regression/out-test/multi-measure-rest-multi-staff-center.txt
$ # no jpeg
$ cp input/regression/out-test/multi-measure-rest-multi-staff-center.eps .
$ epstopdf multi-measure-rest-multi-staff-center.eps # pdf attached
What can I say?
Regards,
/Karl Hammar
<<attachment: rest-collision-beam-note.compare.jpeg>>
multi-measure-rest-multi-staff-center.pdf
Description: multi-measure-rest-multi-staff-center.pdf
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
