Fix a few complaints in python/convertrules.py (issue 583290043 by d...@gnu.org)

[jonas . hahnfeld]

https://codereview.appspot.com/583290043/diff/557180043/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/583290043/diff/557180043/python/convertrules.py#newcode1774
python/convertrules.py:1774: str += "'" * (o + 1)
I agree that this is equivalent, but still very confusing. I would
propose the following which should highlight the intent:
o += 1
if o < 0:
str += ',' * (-o)
elif o > 0:
str += "'" * o

https://codereview.appspot.com/583290043/diff/557180043/python/convertrules.py#newcode3973
python/convertrules.py:3973: if re.search (r"#(banter|jazz)-chordnames",
str):
Is the change from "chord-names" to "chordnames" intentional?

https://codereview.appspot.com/583290043/

Re: Fix a few complaints in python/convertrules.py (issue 583290043 by d...@gnu.org)

[jonas . hahnfeld]

https://codereview.appspot.com/583290043/diff/557180043/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/583290043/diff/557180043/python/convertrules.py#newcode3973
python/convertrules.py:3973: if re.search (r"#(banter|jazz)-chordnames",
str):
On 2020/01/08 08:17:25, hahnjo wrote:

Is the change from "chord-names" to "chordnames" intentional?


Yes it is, I just saw the discussion on the older review.

https://codereview.appspot.com/583290043/

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[David Kastrup]

Erlend Aasland  writes:

> Hey, guys! What’s the status of Guile support in LilyPond? Is there
> still a transition from Guile 1.8 to 2.0 happening, or has 2.0 been
> ditched in favour of 2.2? I did a quick search in the
> bugtracker,
> and there seem to be people who use Guile 2.x with LP.

Guile 2.x (or the upcoming 3.x) continues to be a non-sensible option
for using LilyPond.  The state is "barely working" and "at least 3 times
slower".

-- 
David Kastrup

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[David Kastrup]

Erlend Aasland  writes:

> Right, so we’re sticking with 1.8 for now. Have we ever considered
> throwing out Guile and replacing it with something else? (Yes, I know
> that would be a huge operation.)

Replacing Scheme with something else would be a completely different
application.  Using a different Scheme interpreter would not be easier
than using Guile-2.x .

-- 
David Kastrup

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[Erlend Aasland]

Right, so we’re sticking with 1.8 for now. Have we ever considered throwing out 
Guile and replacing it with something else? (Yes, I know that would be a huge 
operation.)


Erlend

> On 8 Jan 2020, at 13:29, David Kastrup  wrote:
> 
> Erlend Aasland  writes:
> 
>> Hey, guys! What’s the status of Guile support in LilyPond? Is there
>> still a transition from Guile 1.8 to 2.0 happening, or has 2.0 been
>> ditched in favour of 2.2? I did a quick search in the
>> bugtracker,
>> and there seem to be people who use Guile 2.x with LP.
> 
> Guile 2.x (or the upcoming 3.x) continues to be a non-sensible option
> for using LilyPond.  The state is "barely working" and "at least 3 times
> slower".
> 
> -- 
> David Kastrup

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[Erlend Aasland]

I understand. Thanks for your answers.


Erlend

> On 8 Jan 2020, at 13:51, David Kastrup  wrote:
> 
> Erlend Aasland  writes:
> 
>> Right, so we’re sticking with 1.8 for now. Have we ever considered
>> throwing out Guile and replacing it with something else? (Yes, I know
>> that would be a huge operation.)
> 
> Replacing Scheme with something else would be a completely different
> application.  Using a different Scheme interpreter would not be easier
> than using Guile-2.x .
> 
> -- 
> David Kastrup

Re: Status of Guile 2.0 Support (Next Debian release won't ship guile-1.8)

[Erlend Aasland]

Hey, guys! What’s the status of Guile support in LilyPond? Is there still a 
transition from Guile 1.8 to 2.0 happening, or has 2.0 been ditched in favour 
of 2.2? I did a quick search in the 
bugtracker, 
and there seem to be people who use Guile 2.x with LP.


Erlend E. Aasland

Don Armstrong  writes:

> What is the current status of #1055[1] (support for Guile 2.0 in
> lilypond)?

I'm currently working on it.  There is a branch dev/guilev2 with the
current work.  Current objective is to make it through the test suite.
Several crashes so far look like the memory management is borked.

> Debian is going to be dropping guile-1.8 completely, so in order for
> lilypond to be in the next Debian release (and rosegarden, and a few
> other things), I need to have it support guile 2.0 at least a month
> before freeze, which will likely happen in February at the latest.

"Support guile 2.0" by 2015: not sure.  Support it in a manner that
would be preferable to an installation using 1.8: rather dubious.

Be released as stable version 2.20: unlikely.  At best, we'll have a
2.20 branch only open to bug fixes and Guile 2.0 necessitated changes.

But it seems feasible to get Guile 2.0 itself into the state needed to
support LilyPond by the time of the freeze.  Or get convincing
admissions that it isn't there yet, possibly bargaining for a last-time
inclusion of 1.8.

--
David Kastrup

Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[dak]

https://codereview.appspot.com/549350043/diff/581410043/configure.ac
File configure.ac (right):

https://codereview.appspot.com/549350043/diff/581410043/configure.ac#newcode7
configure.ac:7: AC_INIT([LilyPond], [2.21.0], [bug-lilyp...@gnu.org],
[lilypond], [http://lilypond.org/])
Hardwiring the version number in this manner is a real maintenance drag.
 Couldn't autogen.sh create a VERSION.AC file (or something like it)
containing only the version number that is just included here?

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

Reviewers: dak,

Message:
On 2020/01/08 16:18:25, dak wrote:

https://codereview.appspot.com/549350043/diff/581410043/configure.ac
File configure.ac (right):



https://codereview.appspot.com/549350043/diff/581410043/configure.ac#newcode7

configure.ac:7: AC_INIT([LilyPond], [2.21.0],

mailto:[bug-lilyp...@gnu.org],

[lilypond], [http://lilypond.org/])
Hardwiring the version number in this manner is a real maintenance

drag.

Couldn't autogen.sh create a VERSION.AC file (or something like it)

containing

only the version number that is just included here?


I agree that it's essentially duplicated, but it's not that we bump the
version every day. To make sure there's no divergence, I added a check
that the one provided in AC_INIT and in VERSION are the same.

Ideally, I'd like to get rid of the VERSION completely, but apparently
you can build the website without configure'ing the project. I wasn't
sure if that is still used, so I went for this solution.

Description:
Cleanup initialization of configure process

Individual changes:
1. Cleanup directory handling in STEPMAKE_INIT

 * Get rid of code which configures the Stepmake package, that hasn't
   been supported for a long time.
 * Replace $ugh_ugh_autoconf250_builddir by $ac_pwd and @abs_builddi@.
   I think the latter is actually more correct, but $ac_abs_builddir
   not available when executing configure.
 * Replace hacks around $srcdir and @srcdir@ by predefined variables.

2. Drop unused MICRO_VERSION

3. Remove passing of package and invoke AC_INIT correctly

This requires the version information at two locations (VERSION and
configure.ac), so add a check that these two match.

Please review this at https://codereview.appspot.com/549350043/

Affected files (+59, -155 lines):
  M Documentation/contributor/build-notes.itexi
  M VERSION
  M aclocal.m4
  M config.hh.in
  M config.make.in
  M configure.ac
  M make/stepmake.make
  M make/substitute.make
  M po/GNUmakefile
  M stepmake/stepmake/c++-vars.make
  M stepmake/stepmake/compile-vars.make
  M stepmake/stepmake/executable-vars.make
  M stepmake/stepmake/generic-vars.make

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[David Kastrup]

jonas.hahnf...@gmail.com writes:

> Reviewers: dak,
>
> Message:
> On 2020/01/08 16:18:25, dak wrote:
>> https://codereview.appspot.com/549350043/diff/581410043/configure.ac
>> File configure.ac (right):
>
>
> https://codereview.appspot.com/549350043/diff/581410043/configure.ac#newcode7
>> configure.ac:7: AC_INIT([LilyPond], [2.21.0], mailto:[bug-lilyp...@gnu.org],
>> [lilypond], [http://lilypond.org/])
>> Hardwiring the version number in this manner is a real maintenance drag.
>> Couldn't autogen.sh create a VERSION.AC file (or something like it) 
>> containing
>> only the version number that is just included here?
>
> I agree that it's essentially duplicated, but it's not that we bump the
> version every day. To make sure there's no divergence, I added a check
> that the one provided in AC_INIT and in VERSION are the same.
>
> Ideally, I'd like to get rid of the VERSION completely, but apparently
> you can build the website without configure'ing the project. I wasn't
> sure if that is still used, so I went for this solution.

That doesn't answer my question, does it?

-- 
David Kastrup

Cleanup unneeded parts of Stepmake (issue 577280043 by jonas.hahnf...@gmail.com)

[lemzwerg--- via Discussions on LilyPond development]

LGTM, thanks!

https://codereview.appspot.com/577280043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

On 2020/01/08 16:43:24, dak wrote:

mailto:jonas.hahnf...@gmail.com writes:



> Reviewers: dak,
>
> Message:
> On 2020/01/08 16:18:25, dak wrote:
>>

https://codereview.appspot.com/549350043/diff/581410043/configure.ac

>> File configure.ac (right):
>
>
>

https://codereview.appspot.com/549350043/diff/581410043/configure.ac#newcode7

>> configure.ac:7: AC_INIT([LilyPond], [2.21.0],

mailto:[bug-lilyp...@gnu.org],

>> [lilypond], [http://lilypond.org/])
>> Hardwiring the version number in this manner is a real maintenance

drag.

>> Couldn't autogen.sh create a VERSION.AC file (or something like it)
containing
>> only the version number that is just included here?
>
> I agree that it's essentially duplicated, but it's not that we bump

the

> version every day. To make sure there's no divergence, I added a

check

> that the one provided in AC_INIT and in VERSION are the same.
>
> Ideally, I'd like to get rid of the VERSION completely, but

apparently

> you can build the website without configure'ing the project. I

wasn't

> sure if that is still used, so I went for this solution.



That doesn't answer my question, does it?


Maybe I mis-understood your suggestion: I thought you're asking if
configure can create a file that can be used in place of the current
version. That doesn't work because "make website" can be called without
configure'ing (not sure if that is used, it's certainly different from
how other projects using the GNU build system works)

But re-reading your question, you're maybe proposing to have a file that
is included by Autoconf when generating configure? I think that's not
possible with the documented functionality of Autoconf because you can
only do very few things before calling AC_INIT. I've not come across
something that can read a file in that situation.

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[dak]

On 2020/01/08 17:48:36, hahnjo wrote:

On 2020/01/08 16:43:24, dak wrote:
> mailto:jonas.hahnf...@gmail.com writes:
>
> > Reviewers: dak,
> >
> > Message:
> > On 2020/01/08 16:18:25, dak wrote:
> >>

https://codereview.appspot.com/549350043/diff/581410043/configure.ac

> >> File configure.ac (right):
> >
> >
> >


https://codereview.appspot.com/549350043/diff/581410043/configure.ac#newcode7

> >> configure.ac:7: AC_INIT([LilyPond], [2.21.0],
mailto:[bug-lilyp...@gnu.org],
> >> [lilypond], [http://lilypond.org/])
> >> Hardwiring the version number in this manner is a real

maintenance drag.

> >> Couldn't autogen.sh create a VERSION.AC file (or something like

it)

> containing
> >> only the version number that is just included here?
> >
> > I agree that it's essentially duplicated, but it's not that we

bump the

> > version every day. To make sure there's no divergence, I added a

check

> > that the one provided in AC_INIT and in VERSION are the same.
> >
> > Ideally, I'd like to get rid of the VERSION completely, but

apparently

> > you can build the website without configure'ing the project. I

wasn't

> > sure if that is still used, so I went for this solution.
>
> That doesn't answer my question, does it?



Maybe I mis-understood your suggestion: I thought you're asking if

configure can

create a file that can be used in place of the current version.


I have not written a word about "configure" in my question.  I asked
about autogen.sh .


That doesn't
work because "make website" can be called without configure'ing (not

sure if

that is used, it's certainly different from how other projects using

the GNU

build system works)



But re-reading your question, you're maybe proposing to have a file

that is

included by Autoconf when generating configure? I think that's not

possible with

the documented functionality of Autoconf because you can only do very

few things

before calling AC_INIT. I've not come across something that can read a

file in

that situation.


Shouldn't

AC_INIT([LilyPond], include(`VERSION.AC'),
mailto:[bug-lilyp...@gnu.org], [lilypond], [http://lilypond.org/])

work?

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

On 2020/01/08 18:03:36, dak wrote:

On 2020/01/08 17:48:36, hahnjo wrote:
> On 2020/01/08 16:43:24, dak wrote:
> > mailto:jonas.hahnf...@gmail.com writes:
> >
> > > Reviewers: dak,
> > >
> > > Message:
> > > On 2020/01/08 16:18:25, dak wrote:
> > >>

https://codereview.appspot.com/549350043/diff/581410043/configure.ac

> > >> File configure.ac (right):
> > >
> > >
> > >
>

https://codereview.appspot.com/549350043/diff/581410043/configure.ac#newcode7

> > >> configure.ac:7: AC_INIT([LilyPond], [2.21.0],
> mailto:[bug-lilyp...@gnu.org],
> > >> [lilypond], [http://lilypond.org/])
> > >> Hardwiring the version number in this manner is a real

maintenance drag.

> > >> Couldn't autogen.sh create a VERSION.AC file (or something like

it)

> > containing
> > >> only the version number that is just included here?
> > >
> > > I agree that it's essentially duplicated, but it's not that we

bump the

> > > version every day. To make sure there's no divergence, I added a

check

> > > that the one provided in AC_INIT and in VERSION are the same.
> > >
> > > Ideally, I'd like to get rid of the VERSION completely, but

apparently

> > > you can build the website without configure'ing the project. I

wasn't

> > > sure if that is still used, so I went for this solution.
> >
> > That doesn't answer my question, does it?
>
> Maybe I mis-understood your suggestion: I thought you're asking if

configure

can
> create a file that can be used in place of the current version.



I have not written a word about "configure" in my question.  I asked

about

autogen.sh .



> That doesn't
> work because "make website" can be called without configure'ing (not

sure if

> that is used, it's certainly different from how other projects using

the GNU

> build system works)
>
> But re-reading your question, you're maybe proposing to have a file

that is

> included by Autoconf when generating configure? I think that's not

possible

with
> the documented functionality of Autoconf because you can only do

very few

things
> before calling AC_INIT. I've not come across something that can read

a file in

> that situation.



Shouldn't



AC_INIT([LilyPond], include(`VERSION.AC'),

mailto:[bug-lilyp...@gnu.org],

[lilypond], [http://lilypond.org/])



work?


Just putting that line to a configure.ac and running $ autoconf:
configure.ac:1: warning: AC_INIT: not a literal: include(`VERSION.AC')

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

On 2020/01/08 18:09:53, hahnjo wrote:

On 2020/01/08 18:03:36, dak wrote:
> On 2020/01/08 17:48:36, hahnjo wrote:
> > On 2020/01/08 16:43:24, dak wrote:
> > > mailto:jonas.hahnf...@gmail.com writes:
> > >
> > > > Reviewers: dak,
> > > >
> > > > Message:
> > > > On 2020/01/08 16:18:25, dak wrote:
> > > >>

https://codereview.appspot.com/549350043/diff/581410043/configure.ac

> > > >> File configure.ac (right):
> > > >
> > > >
> > > >
> >


https://codereview.appspot.com/549350043/diff/581410043/configure.ac#newcode7

> > > >> configure.ac:7: AC_INIT([LilyPond], [2.21.0],
> > mailto:[bug-lilyp...@gnu.org],
> > > >> [lilypond], [http://lilypond.org/])
> > > >> Hardwiring the version number in this manner is a real

maintenance

drag.
> > > >> Couldn't autogen.sh create a VERSION.AC file (or something

like it)

> > > containing
> > > >> only the version number that is just included here?
> > > >
> > > > I agree that it's essentially duplicated, but it's not that we

bump the

> > > > version every day. To make sure there's no divergence, I added

a check

> > > > that the one provided in AC_INIT and in VERSION are the same.
> > > >
> > > > Ideally, I'd like to get rid of the VERSION completely, but

apparently

> > > > you can build the website without configure'ing the project. I

wasn't

> > > > sure if that is still used, so I went for this solution.
> > >
> > > That doesn't answer my question, does it?
> >
> > Maybe I mis-understood your suggestion: I thought you're asking if

configure

> can
> > create a file that can be used in place of the current version.
>
> I have not written a word about "configure" in my question.  I asked

about

> autogen.sh .
>
> > That doesn't
> > work because "make website" can be called without configure'ing

(not sure if

> > that is used, it's certainly different from how other projects

using the GNU

> > build system works)
> >
> > But re-reading your question, you're maybe proposing to have a

file that is

> > included by Autoconf when generating configure? I think that's not

possible

> with
> > the documented functionality of Autoconf because you can only do

very few

> things
> > before calling AC_INIT. I've not come across something that can

read a file

in
> > that situation.
>
> Shouldn't
>
> AC_INIT([LilyPond], include(`VERSION.AC'),

mailto:[bug-lilyp...@gnu.org],

> [lilypond], [http://lilypond.org/])
>
> work?



Just putting that line to a configure.ac and running $ autoconf:
configure.ac:1: warning: AC_INIT: not a literal: include(`VERSION.AC')


Oh, and the regardlessly generated configure doesn't expand the include.
In fact, it doesn't even care if the file exists, it just has
include(`VERSION.AC') in all places where I would expect the version.

https://codereview.appspot.com/549350043/

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Tue, Jan 7, 2020 at 5:21 PM Marnen Laibow-Koser 
wrote:
[...]

>
> I plan to use LilyPad like the current Mac distributions do.  I agree that
> Frescobaldi might be a better choice in the long run.
>

I got LilyPad to build 64-bit (and run on Mojave), with some modifications
to the existing codebase, which are at
https://github.com/marnen/lilypad/tree/mac-64-bit/macosx (I'll make a pull
request to the main LilyPad repo once I tidy it up a bit).

Now for the 64,000-bit question: the LilyPad .app bundle, as built, of
course doesn't contain the LilyPond binaries.  Does anyone know if there's
any sort of build script or other list stating what files should be copied
into the app bundle?  The README at
https://github.com/gperciva/lilypad/blob/master/macosx/README just suggests
(to my amazement) using rsync to copy the files over from a previous
version of the .app bundle.  Of course, that won't quite work in my case,
but if worse comes to worst, I suppose I could use a directory listing to
make a build script.  But surely something already exists?  Maybe in the
GUB repo?

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[dak]

On 2020/01/08 18:03:36, dak wrote:


>
> But re-reading your question, you're maybe proposing to have a file

that is

> included by Autoconf when generating configure? I think that's not

possible

with
> the documented functionality of Autoconf because you can only do

very few

things
> before calling AC_INIT. I've not come across something that can read

a file in

> that situation.



Shouldn't



AC_INIT([LilyPond], include(`VERSION.AC'),

mailto:[bug-lilyp...@gnu.org],

[lilypond], [http://lilypond.org/])



work?


Hm, doesn't work.  Looks like I need to look more closely at what
autoconf does.

https://codereview.appspot.com/549350043/

Re: macOS 64-bit

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Mittwoch, den 08.01.2020, 13:29 -0500 schrieb Marnen Laibow-Koser:
> On Tue, Jan 7, 2020 at 5:21 PM Marnen Laibow-Koser <
> mar...@marnen.org
> >
> wrote:
> [...]
> 
> > I plan to use LilyPad like the current Mac distributions do.  I agree that
> > Frescobaldi might be a better choice in the long run.
> > 
> 
> I got LilyPad to build 64-bit (and run on Mojave), with some modifications
> to the existing codebase, which are at
> https://github.com/marnen/lilypad/tree/mac-64-bit/macosx
>  (I'll make a pull
> request to the main LilyPad repo once I tidy it up a bit).
> 
> Now for the 64,000-bit question: the LilyPad .app bundle, as built, of
> course doesn't contain the LilyPond binaries.  Does anyone know if there's
> any sort of build script or other list stating what files should be copied
> into the app bundle?  The README at
> https://github.com/gperciva/lilypad/blob/master/macosx/README
>  just suggests
> (to my amazement) using rsync to copy the files over from a previous
> version of the .app bundle.  Of course, that won't quite work in my case,
> but if worse comes to worst, I suppose I could use a directory listing to
> make a build script.  But surely something already exists?  Maybe in the
> GUB repo?

I think GUB just downloads a pre-built version of LilyPad, see the spec
https://github.com/gperciva/gub/blob/master/gub/specs/osx-lilypad.py

Jonas


signature.asc
Description: This is a digitally signed message part

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Wed, Jan 8, 2020 at 2:12 PM Jonas Hahnfeld  wrote:

> Am Mittwoch, den 08.01.2020, 13:29 -0500 schrieb Marnen Laibow-Koser:
> > On Tue, Jan 7, 2020 at 5:21 PM Marnen Laibow-Koser <
> > mar...@marnen.org
> > >
> > wrote:

[...]

>
> > course doesn't contain the LilyPond binaries.  Does anyone know if
> there's
> > any sort of build script or other list stating what files should be
> copied
> > into the app bundle?  The README at
> > https://github.com/gperciva/lilypad/blob/master/macosx/README
> >  just suggests
> > (to my amazement) using rsync to copy the files over from a previous
> > version of the .app bundle.  Of course, that won't quite work in my case,
> > but if worse comes to worst, I suppose I could use a directory listing to
> > make a build script.  But surely something already exists?  Maybe in the
> > GUB repo?
>
> I think GUB just downloads a pre-built version of LilyPad, see the spec
> https://github.com/gperciva/gub/blob/master/gub/specs/osx-lilypad.py


Isn’t that just the .app wrapper without the LilyPond binaries?  After all,
the LilyPond binaries themselves would be built by GUB.


>
> Jonas
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[Carl Sorensen]

How about

AC_INIT([LilyPond],m4_esyscmd(echo `VERSION.AC'))

The documentation says it is permissible to use m4_esyscmd as part of the 
package information strings in AC_INIT.

Carl


On 1/8/20, 11:49 AM, "lilypond-devel on behalf of d...@gnu.org" 
 
wrote:

On 2020/01/08 18:03:36, dak wrote:

> >
> > But re-reading your question, you're maybe proposing to have a file
that is
> > included by Autoconf when generating configure? I think that's not
possible
> with
> > the documented functionality of Autoconf because you can only do
very few
> things
> > before calling AC_INIT. I've not come across something that can read
a file in
> > that situation.

> Shouldn't

> AC_INIT([LilyPond], include(`VERSION.AC'),
mailto:[bug-lilyp...@gnu.org],
> [lilypond], [http://lilypond.org/])

> work?

Hm, doesn't work.  Looks like I need to look more closely at what
autoconf does.

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

On 2020/01/08 19:40:06, c_sorensen wrote:

How about



AC_INIT([LilyPond],m4_esyscmd(echo `VERSION.AC'))



The documentation says it is permissible to use m4_esyscmd as part of

the

package information strings in AC_INIT.



Carl


Not quite, but a variation seems to work. However I find this so ugly
that I'm not willing to pursue this direction. The documentation says
AC_INIT should be called with constant arguments, and we're again trying
to find ways around it :-(

https://codereview.appspot.com/549350043/

Re: macOS 64-bit

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Mittwoch, den 08.01.2020, 14:23 -0500 schrieb Marnen Laibow-Koser:
> 
> 
> On Wed, Jan 8, 2020 at 2:12 PM Jonas Hahnfeld  wrote:
> > Am Mittwoch, den 08.01.2020, 13:29 -0500 schrieb Marnen Laibow-Koser:
> > > On Tue, Jan 7, 2020 at 5:21 PM Marnen Laibow-Koser <
> > > mar...@marnen.org
> > > >
> > > wrote:
> 
> [...]
> > > course doesn't contain the LilyPond binaries.  Does anyone know if there's
> > > any sort of build script or other list stating what files should be copied
> > > into the app bundle?  The README at
> > > https://github.com/gperciva/lilypad/blob/master/macosx/README
> > >  just suggests
> > > (to my amazement) using rsync to copy the files over from a previous
> > > version of the .app bundle.  Of course, that won't quite work in my case,
> > > but if worse comes to worst, I suppose I could use a directory listing to
> > > make a build script.  But surely something already exists?  Maybe in the
> > > GUB repo?
> > 
> > I think GUB just downloads a pre-built version of LilyPad, see the spec
> > https://github.com/gperciva/gub/blob/master/gub/specs/osx-lilypad.py
> 
> Isn’t that just the .app wrapper without the LilyPond binaries?  After all, 
> the LilyPond binaries themselves would be built by GUB. 

I think the files are taken from the packages previously built by GUB
with their (transitive) dependencies. At least that's what the file
gub/installer.py suggests. Not really sure why these are less than all
in root/...


signature.asc
Description: This is a digitally signed message part

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[dak]

On 2020/01/08 19:49:22, hahnjo wrote:

On 2020/01/08 19:40:06, c_sorensen wrote:
> How about
>
> AC_INIT([LilyPond],m4_esyscmd(echo `VERSION.AC'))
>
> The documentation says it is permissible to use m4_esyscmd as part

of the

> package information strings in AC_INIT.
>
> Carl



Not quite, but a variation seems to work. However I find this so ugly

that I'm

not willing to pursue this direction. The documentation says AC_INIT

should be

called with constant arguments, and we're again trying to find ways

around it

:-(


With that invocation, m4_esyscmd is called before AC_INIT is replaced so
it _is_ being called with a constant argument.  It turns out that
m4_include would be the much more sane variant with this usage, but with
m4_esyscmd we can actually write:

# Bootstrap the init process.
AC_INIT([LilyPond], m4_esyscmd([. ./VERSION;echo -n
${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_LEVEL}]),
mailto:[bug-lilyp...@gnu.org], [lilypond], [http://lilypond.org/])

and there is no need to futz with autogen.sh or anything else.

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[Carl Sorensen]

What documentation says AC_INIT should be called with constant arguments?

Quoting from 
https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Initializing-configure.html

"The arguments of AC_INIT must be static, i.e., there should not be any shell 
computation, quotes, or newlines, but they can be computed by M4. This is 
because the package information strings are expanded at M4 time into several 
contexts, and must give the same text at shell time whether used in 
single-quoted strings, double-quoted strings, quoted here-documents, or 
unquoted here-documents. It is permissible to use m4_esyscmd or m4_esyscmd_s 
for computing a version string that changes with every commit to a version 
control system (in fact, Autoconf does just that, for all builds of the 
development tree made between releases)."

This says to me that it is perfectly permissible to use m4_esyscmd to get a 
version string.  And having all our version information in one place and one 
place only seems to be to be a good strategy.

Carl

On 1/8/20, 12:49 PM, "jonas.hahnf...@gmail.com"  
wrote:

On 2020/01/08 19:40:06, c_sorensen wrote:
> How about

> AC_INIT([LilyPond],m4_esyscmd(echo `VERSION.AC'))

> The documentation says it is permissible to use m4_esyscmd as part of
the
> package information strings in AC_INIT.

> Carl

Not quite, but a variation seems to work. However I find this so ugly
that I'm not willing to pursue this direction. The documentation says
AC_INIT should be called with constant arguments, and we're again trying
to find ways around it :-(

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

On 2020/01/08 20:14:20, dak wrote:

On 2020/01/08 19:49:22, hahnjo wrote:
> On 2020/01/08 19:40:06, c_sorensen wrote:
> > How about
> >
> > AC_INIT([LilyPond],m4_esyscmd(echo `VERSION.AC'))
> >
> > The documentation says it is permissible to use m4_esyscmd as part

of the

> > package information strings in AC_INIT.
> >
> > Carl
>
> Not quite, but a variation seems to work. However I find this so

ugly that I'm

> not willing to pursue this direction. The documentation says AC_INIT

should be

> called with constant arguments, and we're again trying to find ways

around it

> :-(



With that invocation, m4_esyscmd is called before AC_INIT is replaced

so it _is_

being called with a constant argument.  It turns out that m4_include

would be

the much more sane variant with this usage, but with m4_esyscmd we can

actually

write:



# Bootstrap the init process.
AC_INIT([LilyPond], m4_esyscmd([. ./VERSION;echo -n
${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_LEVEL}]),
mailto:[bug-lilyp...@gnu.org], [lilypond], [http://lilypond.org/])



and there is no need to futz with autogen.sh or anything else.


Oh, this actually looks pretty ok :O

On 2020/01/08 20:15:10, c_sorensen wrote:

What documentation says AC_INIT should be called with constant

arguments?

looks like I confused / misunderstood some other page...

https://codereview.appspot.com/549350043/

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[Carl Sorensen]

On 1/8/20, 1:30 PM, "jonas.hahnf...@gmail.com"  
wrote:


looks like I confused / misunderstood some other page...


BTW, I neglected earlier to thank you for diving in and removing cruft from the 
stepmake and autoconf files.

That's an important job that I don't really have the chops for doing.

Thank you!

 

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[dak]

On 2020/01/08 20:30:20, hahnjo wrote:

On 2020/01/08 20:14:20, dak wrote:
> On 2020/01/08 19:49:22, hahnjo wrote:
> > On 2020/01/08 19:40:06, c_sorensen wrote:
> > > How about
> > >
> > > AC_INIT([LilyPond],m4_esyscmd(echo `VERSION.AC'))
> > >
> > > The documentation says it is permissible to use m4_esyscmd as

part of the

> > > package information strings in AC_INIT.
> > >
> > > Carl
> >
> > Not quite, but a variation seems to work. However I find this so

ugly that

I'm
> > not willing to pursue this direction. The documentation says

AC_INIT should

be
> > called with constant arguments, and we're again trying to find

ways around

it
> > :-(
>
> With that invocation, m4_esyscmd is called before AC_INIT is

replaced so it

_is_
> being called with a constant argument.  It turns out that m4_include

would be

> the much more sane variant with this usage, but with m4_esyscmd we

can

actually
> write:
>
> # Bootstrap the init process.
> AC_INIT([LilyPond], m4_esyscmd([. ./VERSION;echo -n
> ${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_LEVEL}]),
> mailto:[bug-lilyp...@gnu.org], [lilypond], [http://lilypond.org/])
>
> and there is no need to futz with autogen.sh or anything else.



Oh, this actually looks pretty ok :O


The problematic question is whether ./ is the right source directory in
all questions or whether there is something else we'd need to use.  The
code in autogen.sh for a readonly source directory would not work.  I
doubt anyone uses it, but it could be made to copy the VERSION file
maybe?  I don't see any other simple expedient right now.


On 2020/01/08 20:15:10, c_sorensen wrote:
> What documentation says AC_INIT should be called with constant

arguments?


looks like I confused / misunderstood some other page...




https://codereview.appspot.com/549350043/

Re: The Future

[Dan Eble]

On Jan 8, 2020, at 12:53, Zone Dremik  wrote:
> 
> I'm bound to ask; is this the end of for support of Mac OS?

I suggest checking the lilypond-devel archive, where people have been 
discussing macOS this very day.
https://lists.gnu.org/archive/html/lilypond-devel/2020-01/msg00052.html
— 
Dan

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnf...@gmail.com)

[jonas . hahnfeld]

On 2020/01/08 20:46:37, dak wrote:

On 2020/01/08 20:30:20, hahnjo wrote:
> On 2020/01/08 20:14:20, dak wrote:
> > On 2020/01/08 19:49:22, hahnjo wrote:
> > > On 2020/01/08 19:40:06, c_sorensen wrote:
> > > > How about
> > > >
> > > > AC_INIT([LilyPond],m4_esyscmd(echo `VERSION.AC'))
> > > >
> > > > The documentation says it is permissible to use m4_esyscmd as

part of

the
> > > > package information strings in AC_INIT.
> > > >
> > > > Carl
> > >
> > > Not quite, but a variation seems to work. However I find this so

ugly that

> I'm
> > > not willing to pursue this direction. The documentation says

AC_INIT

should
> be
> > > called with constant arguments, and we're again trying to find

ways around

> it
> > > :-(
> >
> > With that invocation, m4_esyscmd is called before AC_INIT is

replaced so it

> _is_
> > being called with a constant argument.  It turns out that

m4_include would

be
> > the much more sane variant with this usage, but with m4_esyscmd we

can

> actually
> > write:
> >
> > # Bootstrap the init process.
> > AC_INIT([LilyPond], m4_esyscmd([. ./VERSION;echo -n
> > ${MAJOR_VERSION}.${MINOR_VERSION}.${PATCH_LEVEL}]),
> > mailto:[bug-lilyp...@gnu.org], [lilypond], [http://lilypond.org/])
> >
> > and there is no need to futz with autogen.sh or anything else.
>
> Oh, this actually looks pretty ok :O



The problematic question is whether ./ is the right source directory

in all

questions or whether there is something else we'd need to use.  The

code in

autogen.sh for a readonly source directory would not work.  I doubt

anyone uses

it, but it could be made to copy the VERSION file maybe?  I don't see

any other

simple expedient right now.


Autoconf doesn't consider this case in their git repository either, they
call a relative script...

https://codereview.appspot.com/549350043/

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Wed, Jan 8, 2020 at 2:59 PM Jonas Hahnfeld  wrote:

> Am Mittwoch, den 08.01.2020, 14:23 -0500 schrieb Marnen Laibow-Koser:
> >
> >
> > On Wed, Jan 8, 2020 at 2:12 PM Jonas Hahnfeld  wrote:

[...]

>
> > > I think GUB just downloads a pre-built version of LilyPad, see the spec
> > > https://github.com/gperciva/gub/blob/master/gub/specs/osx-lilypad.py
> >
> > Isn’t that just the .app wrapper without the LilyPond binaries?  After
> all, the LilyPond binaries themselves would be built by GUB.
>
> I think the files


Meaning the LilyPond binaries?

are taken from the packages previously built by GUB
> with their (transitive) dependencies.


That’s what I’d assume.

At least that's what the file
> gub/installer.py suggests.


Yes, although it seems to have a blacklist of files to delete rather than a
white
list of files to copy.

Not really sure why these are less than all
> in root/...


Not sure I understand what you mean here.

On another note: I’m starting to have the sense that no one currently
involved in the project really understands GUB.  Is that so?  If so, it’s
worrisome...

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Issue 5656: Warn about accessing the Global context explicitly (issue 567050043 by nine.fierce.ball...@gmail.com)

[thomasmorley65]

I know several custom codings (defining a new grob, thus the need to
reintroduce all-grob-descriptions at Global level) using

\layout {
  \context {
\Global
\grobdescriptions #all-grob-descriptions
  }
}

will this be disallowed with this patch?
Then I'd object.

If it stays allowed, why disallow \context Global etc then?







https://codereview.appspot.com/567050043/

Re: Issue 5656: Warn about accessing the Global context explicitly (issue 567050043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

Reviewers: thomasmorley651,

Message:
On 2020/01/09 00:33:35, thomasmorley651 wrote:

I know several custom codings (defining a new grob, thus the need to

reintroduce

all-grob-descriptions at Global level) using



\layout {
   \context {
 \Global
 \grobdescriptions #all-grob-descriptions
   }
}



will this be disallowed with this patch?
Then I'd object.


This patch doesn't touch context definitions, so I don't expect anything
about them to change.


If it stays allowed, why disallow \context Global etc then?


*Shrug*  I'm trying to understand what was intended, cover it in tests,
and fix it if necessary.  In the future, I'd like to improve the
maintainability of the code.  If I've misinterpreted how this should
work, I'm open to correction.

This is the description of the Global context:
\description "Hard coded entry point for LilyPond.  Cannot be
tuned."
Does that mean that \set Global.whatever = ... should be disallowed?  It
sounds like it, and it seems not to work in master, and the warning
behavior is inconsistent.  Try this example, if you wish.

\version "2.21.0"

\layout {
  \context {
\Global
\unset instrumentName
  }
  \context {
\Score
\unset instrumentName
  }
  \context {
\Staff
\unset instrumentName
  }
}

\context Global {
  %% This has no apparent effect and there is no warning.
  \set Global.instrumentName = "Global 1"
  a'1
}

\context Score {
  b'1
}

\context Score {
  %% This issues a warning but engraves the name anyway.  I think it
  %% falls back to setting the property in the current context
  %% (Score), but I haven't verified that.
  \set Global.instrumentName = "Global 2"
  c''1
}

\context Score {
  d''1
}

\context Score {
  \set Score.instrumentName = "Score"
  e''1
}

Regards,
--
Dan

Description:
https://sourceforge.net/p/testlilyissues/issues/5656/

This is another nudge in the direction of consistency in handling
contexts.

1: Add regression test for \new Global
This passes without changes: LilyPond issues a warning about \new
Global.

2: Warn about trying to access the Global context explicitly
Warn for \context Global and \set Global.property as for \new Global.

Please review this at https://codereview.appspot.com/567050043/

Affected files (+38, -7 lines):
  A input/regression/context-global-find.ly
  A input/regression/context-global-new.ly
  M lily/context.cc
  M lily/include/context.hh
  M lily/include/global-context.hh


Index: input/regression/context-global-find.ly
diff --git a/input/regression/context-global-find.ly  
b/input/regression/context-global-find.ly

new file mode 100644
index  
..fd50457cb0e814bb2e3e1bbcfaad309b957a4f96

--- /dev/null
+++ b/input/regression/context-global-find.ly
@@ -0,0 +1,16 @@
+\version "2.21.0"
+
+\header {
+  texidoc = "User code is not allowed to access the Global context.
+  The visual output of this test is not important."
+}
+
+#(ly:set-option 'warning-as-error #t)
+%% once for \context and once for \set
+#(ly:expect-warning (_ "cannot find or create context: ~a") 'Global)
+#(ly:expect-warning (_ "cannot find or create context: ~a") 'Global)
+
+\context Global {
+  \set Global.instrumentName = "Global"
+  s1
+}
Index: input/regression/context-global-new.ly
diff --git a/input/regression/context-global-new.ly  
b/input/regression/context-global-new.ly

new file mode 100644
index  
..fceb6fe4fc5d9624b9b2724c18e2aae3643101bf

--- /dev/null
+++ b/input/regression/context-global-new.ly
@@ -0,0 +1,11 @@
+\version "2.21.0"
+
+\header {
+  texidoc = "User code is not allowed to create a Global context.
+  The visual output of this test is not important."
+}
+
+#(ly:set-option 'warning-as-error #t)
+#(ly:expect-warning (_ "cannot create context: ~a") 'Global)
+
+\new Global s1
Index: lily/context.cc
diff --git a/lily/context.cc b/lily/context.cc
index  
9f6ec8ebdb8184b78a859916e3d46b5ad747dc7d..b739a020de8ae62adb5c2c40a0c34d15c6f588d3  
100644

--- a/lily/context.cc
+++ b/lily/context.cc
@@ -132,6 +132,13 @@ Context *
 Context::find_create_context (SCM n, const string &id,
   SCM operations)
 {
+  // Searching below in recursive calls can find contexts beyond those  
that are

+  // visible when looking just down and up from the starting point.  The
+  // regression test lyric-combine-polyphonic.ly has a reasonably simple
+  // example of how this can be useful.
+  if (Context *existing = find_context_below (this, n, id))
+return existing->is_accessible_to_user () ? existing : nullptr;
+
   /*
 Don't create multiple score contexts.
   */
@@ -145,13 +152,6 @@ Context::find_create_context (SCM n, const string &id,
 }
 }

-  // Searching below in recursive calls can find contexts beyond those  
that are

-  // visible when looking just down and up from the starting point.  The
-  // regression test lyric-combine-polyphonic.ly has a reasonably simple
-  // example of how