[Top][All Lists]

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

Re: Patchy email

From: David Kastrup
Subject: Re: Patchy email
Date: Tue, 19 Jun 2018 15:00:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

"James Lowe" <address@hidden> writes:

> David

>> Thats the musicxml2ly thing again.  I now locally did make & make
>> install now and restarted to see whether this still breaks.
>> We probably need to make sure to use the right versions of
>> musicxml2ly (the ones in the build tree rather than the installed
>> ones) in all respects. This failed build appears to be because of
>> some module being taken from the installed version rather than the
>> build tree.  I expect the next run to go through, but this makes
>> tests non-representative.
>> --
> [James:] I don't understand. I don't have this problem. Are you saying that
> your patchy is not building LP from the same 'tree' as you are testing the
> patch from?

No.  I am saying that my patchy uses some scraps of the currently
installed musicxml2ly version rather than using everything from the
build tree.  Your tests are likely immune against this problem because
you don't have any installed version of LilyPond (and musicxml2ly) in
the VMs where you do the building and apparently that is enough to make
sure this problem does not happen: the build appears to find the
musicxml2ly stuff in the build tree as long as no installed version
exists that it could take instead.

> I am always a bit confused when I don't get the same problem as others
> that run the scripts I do.

As I predicted, this problem disappeared after I did make && sudo make
install .  But it means that the parts of the test involving musicxml2ly
might yield false negatives _or_ false positives when there is an
installed version of musicxml2ly around.

David Kastrup

reply via email to

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