Issue 5829: Re-indent all mf files (issue 573610048 by torsten.haemme...@web.de)

Reviewers: , Message: Please review. Ta, Torsten Description: Issue 5829: Re-indent all mf files As a second step after having replaced all tabs by 8 character indentations, these indentations will now be reduced to 2 characters. "Tabs are used..." passage removed from Contributor's Guide

Re: Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

On 2020/03/07 21:36:04, hahnjo wrote: > On 2020/03/07 21:24:48, hanwenn wrote: > > On 2020/03/07 19:23:13, Dan Eble wrote: > > > On 2020/03/07 18:59:54, hahnjo wrote: > > > > I think this is wrong. Instead 'make test' should recurse into the > > > > subdirectories. > > > > > > Agreed. That would

Re: Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

On 2020/03/07 21:36:04, hahnjo wrote: > On 2020/03/07 21:24:48, hanwenn wrote: > > I don't care much what we call this, and we can certainly change this, but > > it's historically been called check. > > Yes, but 'check' for LilyPond also does the comparison to test-baseline. As > 'check' depends

aclocal.m4: Remove code without function. (issue 557600043 by lemzw...@googlemail.com)

LGTM passes make build. https://codereview.appspot.com/557600043/

Re: Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

LGTM maybe add a TODO for the clumsy thing. https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc File lily/text-interface.cc (right): https://codereview.appspot.com/555420043/diff/549710049/lily/text-interface.cc#newcode70 lily/text-interface.cc:70: SCM ligature =

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Werner LEMBERG writes: >> I have no beef with deprecating it. > > What about the following route? For guile, I would add support for > `guile-config`, using the following algorithm (with item 1 already > implemented). > > 1. Search for a guile `.pc` file, checking whether version 1.8.x, >

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

https://codereview.appspot.com/581770043/diff/571840081/scripts/build/output-distance.py File scripts/build/output-distance.py (left): https://codereview.appspot.com/581770043/diff/571840081/scripts/build/output-distance.py#oldcode1074 scripts/build/output-distance.py:1074: print('writing %s' %

Fix most encoding problems with Guile 2.x (issue 555420043 by jonas.hahnf...@gmail.com)

Reviewers: , Message: FYI: This makes a `check` with Guile 2.2 for `baseline` from Guile 1.8 almost clean. Left are: * output races, ie `input/regression/option-help.log`, `input/regression/woodwind-diagrams-key-lists.log`, `input/regression/safe.log` * rounding differences:

Re: Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

On 2020/03/07 21:24:48, hanwenn wrote: > On 2020/03/07 19:23:13, Dan Eble wrote: > > On 2020/03/07 18:59:54, hahnjo wrote: > > > I think this is wrong. Instead 'make test' should recurse into the > > > subdirectories. > > > > Agreed. That would be here in the top-level GNUMakefile.in: > > > >

Re: Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

Reviewers: hahnjo, Dan Eble, Message: On 2020/03/07 19:23:13, Dan Eble wrote: > On 2020/03/07 18:59:54, hahnjo wrote: > > I think this is wrong. Instead 'make test' should recurse into the > > subdirectories. > > Agreed. That would be here in the top-level GNUMakefile.in: > > test: test-pre >

Re: Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

On 2020/03/07 18:59:54, hahnjo wrote: > I think this is wrong. Instead 'make test' should recurse into the > subdirectories. Agreed. That would be here in the top-level GNUMakefile.in: test: test-pre @echo 'To begin investigating regression-test crashes, use' @echo @echo

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 18:55:02, hanwenn wrote: > > On 2020/03/07 18:40:57, Dan Eble wrote: > > > Don't you think these two should be combined? I don't see value in leaving > > > the first commit with an incorrect target name. > > > > I'll send this separately. It has nothing to do with output-distance.

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

The logging and diffing changes basically LGTM (see my questions). I paid no attention to other changes (self-test, stencil comparison, python idioms, etc.). https://codereview.appspot.com/581770043/diff/571840081/scripts/build/output-distance.py File scripts/build/output-distance.py (left):

Fix test target name in python/GNUmakefile (issue 575790044 by hanw...@gmail.com)

I think this is wrong. Instead 'make test' should recurse into the subdirectories. Likely we should also fix this for flower IIRC https://codereview.appspot.com/575790044/

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 18:54:04, hanwenn wrote: > On 2020/03/07 18:40:57, Dan Eble wrote: > > On 2020/03/07 17:49:55, hanwenn wrote: > > > it's a sequence of 6 commmits, which you can inspect here: > > > > > > https://github.com/hanwen/lilypond/pull/2 > > > > Don't you think these two should be

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 18:54:04, hanwenn wrote: > On 2020/03/07 18:40:57, Dan Eble wrote: > > On 2020/03/07 17:49:55, hanwenn wrote: > > > it's a sequence of 6 commmits, which you can inspect here: > > > > > > https://github.com/hanwen/lilypond/pull/2 > > > > Don't you think these two should be

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 18:40:57, Dan Eble wrote: > On 2020/03/07 17:49:55, hanwenn wrote: > > it's a sequence of 6 commmits, which you can inspect here: > > > > https://github.com/hanwen/lilypond/pull/2 > > Don't you think these two should be combined? I don't see value in leaving the > first commit

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 18:47:00, Dan Eble wrote: > On 2020/03/07 17:49:55, hanwenn wrote: > > it's a sequence of 6 commmits, which you can inspect here: > > > > https://github.com/hanwen/lilypond/pull/2 > > The fact that the HTML table now includes rows for removed files is worth > mentioning in this

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 17:49:55, hanwenn wrote: > it's a sequence of 6 commmits, which you can inspect here: > > https://github.com/hanwen/lilypond/pull/2 The fact that the HTML table now includes rows for removed files is worth mentioning in this change. commit

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 17:49:55, hanwenn wrote: > it's a sequence of 6 commmits, which you can inspect here: > > https://github.com/hanwen/lilypond/pull/2 Don't you think these two should be combined? I don't see value in leaving the first commit with an incorrect target name. commit

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

> I have no beef with deprecating it. What about the following route? For guile, I would add support for `guile-config`, using the following algorithm (with item 1 already implemented). 1. Search for a guile `.pc` file, checking whether version 1.8.x, 2.2.x, or 2.0.x is present (in this

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

On 2020/03/07 17:34:03, Dan Eble wrote: > The title of the review is "5824 Fix test target name in python/GNUmakefile" but > the title of ticket 5824 is "output-distance refactor". It's hard to tell what > you want us to review. Everything? Just the makefiles? Just output-distance? > Please

Re: Fix test target name in python/GNUmakefile (issue 581770043 by hanw...@gmail.com)

The title of the review is "5824 Fix test target name in python/GNUmakefile" but the title of ticket 5824 is "output-distance refactor". It's hard to tell what you want us to review. Everything? Just the makefiles? Just output-distance? Please update the title and description in both places

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 16:24 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > hah...@hahnjo.de > > > > > > > writes: > > > > Am Samstag, den 07.03.2020, 11:19

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On Sat, Mar 7, 2020 at 12:41 PM David Kastrup wrote: > > Han-Wen Nienhuys writes: > > > On Sat, Mar 7, 2020 at 2:20 AM wrote: > > > >> getting there. And as long as Guile-2.2 crashes frequently with > >> segfaults when used within LilyPond, > > > > Can you file a bug report for any remaining

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On Sat, Mar 7, 2020 at 4:30 PM David Kastrup wrote: > that starts up 3 copies of LilyPond for large workloads, as well as with > 3 jobs in other directories. can you point me to places within the build system where that would happen? AFAIK, our build is only parallel per directory, see here

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

thomasmorle...@gmail.com writes: > On 2020/03/07 12:39:31, dak wrote: >> >> Harm has a system with memory pressure. That means that he so far has >> only been able to work with >> >> CPU_COUNT=2 make -j2 doc > > Well, > CPU_COUNT=3 make -j3 doc > is mostly no problem Ok. >> Since now

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Jonas Hahnfeld writes: > Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup: >> Jonas Hahnfeld < >> hah...@hahnjo.de >> > writes: >> >> > Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup: >> > > We are not talking about "keep everything compatible". We are talking >> >

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On 2020/03/07 12:39:31, dak wrote: > Han-Wen Nienhuys writes: > > > On Fri, Mar 6, 2020 at 11:18 PM wrote: > >> > >> Sigh. I just noticed that opposed to the patch title, this does not > >> just introduce a file lock for lilypond-book but _also_

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 13:53 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup: > > > We are not talking about "keep everything compatible". We are talking > > > about making changes in a manner

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Jonas Hahnfeld writes: > Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup: >> >> We are not talking about "keep everything compatible". We are talking >> about making changes in a manner where they don't trip people up. They >> way to deprecate a way of doing things is not to

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

Han-Wen Nienhuys writes: > On Fri, Mar 6, 2020 at 11:18 PM wrote: >> >> Sigh. I just noticed that opposed to the patch title, this does not >> just introduce a file lock for lilypond-book but _also_ changes the >> build system such that now almost double the number of allocated jobs >> get

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

Han-Wen Nienhuys writes: > On Sat, Mar 7, 2020 at 2:20 AM wrote: > >> getting there. And as long as Guile-2.2 crashes frequently with >> segfaults when used within LilyPond, > > Can you file a bug report for any remaining Guile 2.2 crashes? I am > not aware of any. Just recently two segfaults

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 11:34 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup: > > > David Kastrup < > > > d...@gnu.org > > > > > > > writes: > > > > If I previously did > > > > > > > >

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 11:24 +0100 schrieb Werner LEMBERG: > >> I updated my build script, see below. > > > > > > How did you notice that you had to? > > > Since I don't have guile 2.x installed the problem was immediately > visible. > > >> Note that I install texi2html 1.82 and guile

Re: Add a cooperative FS lock to lilypond-book. (issue 555360043 by hanw...@gmail.com)

On Fri, Mar 6, 2020 at 11:18 PM wrote: > > Sigh. I just noticed that opposed to the patch title, this does not > just introduce a file lock for lilypond-book but _also_ changes the > build system such that now almost double the number of allocated jobs > get used. It would be good if different

Re: Accept GUILE 2 without extra configure options (issue 569390043 by hanw...@gmail.com)

On Sat, Mar 7, 2020 at 2:20 AM wrote: > getting there. And as long as Guile-2.2 crashes frequently with > segfaults when used within LilyPond, Can you file a bug report for any remaining Guile 2.2 crashes? I am not aware of any. -- Han-Wen Nienhuys - hanw...@gmail.com -

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Jonas Hahnfeld writes: > Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup: >> David Kastrup < >> d...@gnu.org >> > writes: >> >> > If I previously did >> > >> > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./configure >> > ./config.status --recheck >> > >> > then the

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 11:19 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Samstag, den 07.03.2020, 10:37 +0100 schrieb Werner LEMBERG: > > > > > > Is there anybody who recently built with a non-system version of > > > > > > Guile-1.8 intentionally?

check_translation crashes

Hi all, As I'm done with the French translations for 2.20, I'd like to now take care of 2.21 but… my workflow is now broken and I'm not able to diagnose what's wrong. The only change in the body of check_translation.py since 2009 has been introduced with issue 5646. A "python --version" gives

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

>> I updated my build script, see below. > > How did you notice that you had to? Since I don't have guile 2.x installed the problem was immediately visible. >> Note that I install texi2html 1.82 and guile 1.8.8 in >> `/uar/local/opt`. > > So what do you do if you also have guile-2.2 and

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Jonas Hahnfeld writes: > Am Samstag, den 07.03.2020, 10:37 +0100 schrieb Werner LEMBERG: >> >>> Is there anybody who recently built with a non-system version of >> >> >>> Guile-1.8 intentionally? >> >> >> >> >> >> I do this all the time. >> >> > >> >> > So how did you do it last week? >>

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Werner LEMBERG writes: Is there anybody who recently built with a non-system version of Guile-1.8 intentionally? >>> >>> I do this all the time. >> >> So how did you do it last week? > > I updated my build script, see below. How did you notice that you had to? > Note that I install

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

>> As I said: I believe the proper action is to make LilyPond's >> `configure` script emit a warning if it finds GUILE_CONFIG set. > > I disagree: Why do we have to keep everything compatible for a new > *major* release like it used to be in the past? That's very > prohibitive of any

Re: modularize `aclocal.m4`?

>> I suggest to use `aclocal` again, modularizing the current stuff in >> `aclocal.m4` by splitting it into various `.m4` files in a `m4` >> top-level subdirectory. > > +1 for doing this, but this is a very low-level tooling change. I'm > in favor of doing 2.21.0 first. OK. Add as issue #5831

git-cl: Problem setting 'owner' field

Folks, I can use `git-cl` just fine. However, I always get the message Problem setting patch status for Allura issue and the 'owner' field of the created SF issue is not properly set. Any idea how to fix this? Werner

Fix Windows resource to enable manifest (issue 551580044 by truer...@gmail.com)

LGTM https://codereview.appspot.com/551580044/

Re: modularize `aclocal.m4`?

Am Samstag, den 07.03.2020, 10:27 +0100 schrieb Werner LEMBERG: > In standard GNU projects, the `aclocal.m4` file gets auto-generated > with the `aclocal` script; the necessary M4 scripts are either taken > from the system or from a directory that gets specified with some > command line options to

Re: aclocal.m4: Update PKG_* macros to pkg-config 0.29.2 (issue 551590044 by lemzw...@googlemail.com)

Reviewers: hanwenn, hahnjo, Message: > > can we include this rather than copy & paste? > > This would require generating aclocal.m4 by aclocal as > part of generating configure. I'm all for doing this, > but I'd avoid doing this level of tooling changes > before 2.21.0 Seconded. Description:

modularize `aclocal.m4`?

In standard GNU projects, the `aclocal.m4` file gets auto-generated with the `aclocal` script; the necessary M4 scripts are either taken from the system or from a directory that gets specified with some command line options to `aclocal`. Looking into the git history of LilyPond's `aclocal.m4`

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 10:37 +0100 schrieb Werner LEMBERG: > >>> Is there anybody who recently built with a non-system version of > > >>> Guile-1.8 intentionally? > > >> > > >> I do this all the time. > > > > > > So how did you do it last week? > > > I updated my build script, see

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Am Samstag, den 07.03.2020, 08:54 +0100 schrieb David Kastrup: > David Kastrup < > d...@gnu.org > > writes: > > > If I previously did > > > > GUILE_CONFIG=/usr/local/tmp/guile-1.8/bin/guile-config ./configure > > ./config.status --recheck > > > > then the Guile configuration was reused. If I

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

>>> Is there anybody who recently built with a non-system version of >>> Guile-1.8 intentionally? >> >> I do this all the time. > > So how did you do it last week? I updated my build script, see below. Note that I install texi2html 1.82 and guile 1.8.8 in `/uar/local/opt`. >> Usually, I try to

Re: aclocal.m4: Update PKG_* macros to pkg-config 0.29.2 (issue 551590044 by lemzw...@googlemail.com)

The update LGTM On 2020/03/07 09:32:47, hanwenn wrote: > https://codereview.appspot.com/551590044/diff/553640043/aclocal.m4 > File aclocal.m4 (right): > > https://codereview.appspot.com/551590044/diff/553640043/aclocal.m4#newcode1127 > aclocal.m4:1127: # pkg.m4 - Macros to locate and utilise

Re: output-distance: treat non-existent files as empty string (issue 583590043 by hanw...@gmail.com)

abandoning for 5824 https://codereview.appspot.com/583590043/

aclocal.m4: Update PKG_* macros to pkg-config 0.29.2 (issue 551590044 by lemzw...@googlemail.com)

https://codereview.appspot.com/551590044/diff/553640043/aclocal.m4 File aclocal.m4 (right): https://codereview.appspot.com/551590044/diff/553640043/aclocal.m4#newcode1127 aclocal.m4:1127: # pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf -*- can we include this rather than copy

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

> For example, FreeType's `configure --help` output produces > > ... > PKG_CONFIG path to pkg-config utility > PKG_CONFIG_PATH > directories to add to pkg-config's search path > PKG_CONFIG_LIBDIR > path overriding pkg-config's built-in search path >

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Werner LEMBERG writes: >>> and all of those messages are auto-generated. >> >> So? This does not provide a documented way of getting Guile >> activated at all unless you are a 14th level system building >> magician. > > I'll try to update the documentation, too. > >> So the correct way is to

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

>> and all of those messages are auto-generated. > > So? This does not provide a documented way of getting Guile > activated at all unless you are a 14th level system building > magician. I'll try to update the documentation, too. > So the correct way is to continue _heeding_ GUILE_CONFIG

Re: config.status has been broken by issue 5780 "Accept GUILE 2 without extra configure options"

Werner LEMBERG writes: >> In addition, PKG_CONFIG_PATH is not documented in our configuration >> or with ./configure --help. >> >> How to fix? > > I will take care of this. Reason is that in calls to `PKG_...`, > `configure.ac` often uses the explicit argument `true`, which prevents > the