lilypond-devel
[Top][All Lists]
Advanced

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

Re: expected outcome of make check


From: Carl Sorensen
Subject: Re: expected outcome of make check
Date: Mon, 28 Oct 2019 19:41:30 +0000
User-agent: Microsoft-MacOutlook/10.10.f.191014


´╗┐On 10/28/19, 1:35 PM, "lilypond-devel on behalf of Jonas Hahnfeld" 
<lilypond-devel-bounces+c_sorensen=address@hidden on behalf of address@hidden> 
wrote:

    Am Samstag, den 26.10.2019, 08:43 +0100 schrieb James:
    > 1. ./autogen --noconfigure
    > 
    > 2. mkdir build
    > 
    > 3. cd build
    > 
    > 4 ../configure --disable-optimising
    > 
    > 5. make -j7 CPU_COUNT=7
    > 
    > 6. make -j7 CPU_COUNT=7 test-baseline
    > 
    > 7. make -j7 CPU_COUNT=7 check
    > 
    > 8.
    > 
    > [...]
    > 
    > It seems that patch testing is getting more and more unreliable and time 
    > consuming for me these last few months - I am the only one that bothers 
    > to do it in case you didn't get that either.
    
    So in trying to help, I'd need some guidance on what is the expected
    outcome of make check. According to section 9.4 of CG, I should only
    see input/regression/test-output-distance.ly but I also see differently
    positioned dots in input/regression/rest-dot-position.ly without
    applying any patch on the current master. In the past I've also
    sometimes seen changes in input/regression/merge-rests-engraver.ly, but
    not today.
    Is that something related to my environment? I've also tried above's
    ../configure --disable-optimising in the past, without success.

My understanding is that rest-dot-position.ly and merge-rests-engraver.ly 
sometimes show up differently on different runs and sometimes show up the same. 
So there is some judgement required when looking at the output for these two 
regtests.

Thanks for looking into this!

Carl
 


reply via email to

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