David Kastrup <d...@gnu.org> writes: > Knut Petersen <knut_peter...@t-online.de> writes: > >> Hi David! >> >> Thank you for the information you provided. Something is really broken, >> but after quite some time of debugging, I'm beginning to wonder if it really >> is my patch / system or if it might be that origin/master is broken after >> all. >> >> Could you please verify if (after adapting the arguments to configure in >> line 6) executing the following commands in your local lilypond repository >> succeeds? Be aware that there is a 'git clean' command, so save your work >> first! >> >> git clean -dfx > > I am not going to git-clean on my current repository/workdirectory since > there is too much temporary stuff in there I might still need. I will > create a separate clone. > >> git checkout origin/master >> ./autogen.sh --noconfigure >> mkdir -p build >> cd build >> ../configure --prefix=<path_to_target_dir> >> --with-urwotf-dir=<path_to_urw-core35-fonts_dir> > > I don't have urwotf fonts but doubt that would be related to the > musicxml2ly issues. > >> make -j 11 CPU_COUNT=11 all >> make -j 11 CPU_COUNT=11 test-baseline >> >> Making test-baseline really should succeed - on my system it does _not_ >> succeed >> with the current origin/master. If making test-baseline does not >> succeed: Does it >> succeed with my patch (1c51a616e289fffb918942c8f1e189ab50809157)? >> >> Is there a safe way to execute a local patchy test? > > Patchy does nothing you cannot do manually. I don't remember offhand > whether it builds in-place or out-of-place. lilypond-patchy-staging > does not work with "make check" or "make test-baseline": it merely does > make all, make test, and make doc . I haven't created a test-baseline > for myself in quite a bit of time. I'll do that first in my local setup > to check whether that still works.
And here are the results from a freshly cloned tree: with your patch, test-baseline fails. Without it, it succeeds. The musicxml error clearly is due to the way you rewrote chord mode output. Either you forgot to cater for some case (in which case it would be surprising that it succeeds at your site), or the committed patch does not contain all the changes you did at your site (have you checked cherry-picking the version pushed to staging?). Or our environment differs in some crucial detail. Or, given the rather bland symptoms, the build procedures on your and/or my site pick up part of locally installed files rather than just the build tree, and the corresponding mismatch of the code (more than one Python file is changed by the patch) leads to the problematic output. Would any log files help? I can rerun make test (both successfully and unsuccessfully) with redirected log files and probably also not use multithreading in order to give comparable log files. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
