Re: [Notensatz im 21. Jahrhundert] Lily+Scheme bootcamp?

[Kieren MacMillan]

Hi Harm,

> my talk would be probably of some interest for you.

It absolutely is.  =)

> Alas, it will be in german, so I can't imagine how helpful it would be for 
> you.

Ja, es ist so lange her, dass ich Deutsch gesprochen habe, dass ich fast alles 
vergessen habe!! Doch ich werde da sein.

> Apart from the problem finding a slot for it, as Urs already
> mentioned, such a meeting would be a great place for it. Maybe we can
> arrange something more or less ad hoc once we meet there.

Looking forward to whatever I can soak up during the conference.

Danke schön!
Kieren.

p.s.

> I'd be interested where you think the obstacles guile <-> LilyPond
> […] Where do _you_ think are the problems?

To be honest, the biggest obstacle for me is simply being able to put the time 
in. The initial learning curve — the combination of Scheme syntax and even the 
"Hello World" handful of must-use functions to manipulate Lilypond grobs — 
seems daunting enough that I haven’t prioritized diving in. I’m quite sure I’d 
be able to answer your question better after getting past the starting line and 
hitting actual technical/understanding roadblocks.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Savannah push access question

[David Kastrup]

Dan Eble  writes:

> I recently started using a git GUI, GitUp, which sometimes infers that
> I might want to delete origin/staging, and offers to do it for me.
> Needless to say, I don't want that; and I've suggested in the GitUp
> issue tracker that even prompting me is a defect, in the light of this
> project's workflow.
>
> My question here is, do I need to maintain extreme caution if I
> continue using this tool?  Would the git server actually delete
> origin/staging if I hit the wrong button by mistake?

Yes, it would.  If staging does not pass tests, the way to reset it to
something else is (usually by me) to delete it and push a different
commit, usually just origin/master in order to reset it.  The only way
to remove a commit from any branch, the way the repository is set up, is
to delete the branch and push a different commit.  Even a forced push to
an existing branch will not allow to remove a commit from the Savannah
repository, so forcing the push has no effect.

So yes, every branch (including master by the way) can be deleted by any
user.  It is suggested to exercise a lot of diligence before deciding to
do so, and only doing it manually in the case it is necessary is not a
large encumbrance compared to the annoyance that may ensue.

So I'd suggest to be able to set the tool up in a manner where it will
not easily delete branches.

-- 
David Kastrup

Re: [Notensatz im 21. Jahrhundert] Lily+Scheme bootcamp?

[Thomas Morley]

Am Mo., 13. Jan. 2020 um 22:00 Uhr schrieb Urs Liska :
>
> Am Montag, den 13.01.2020, 15:42 -0500 schrieb Kieren MacMillan:
> > Hello future Salzburg-ers!
> >
> > Knowing the way my life works, and the fact that I’ll be in Salzburg
> > for four days without the normal distractions (family, etc.), and at
> > hand will be a rather wonderful collection of brains and facilities…
> > Is there any way that someone (Urs? Harm? David N?) could run a
> > relatively short (90'?) "Intro to Scheme-ing In Lilypond" bootcamp?
>
> Hm, and when? Right now I can't see a slot for something like that. The
> problem *I* see with these four days is basically the programme forcing
> too many decisions what to attend and what to miss already ...
>
> Best
> Urs
>
> > Nothing too formal: just a stream-of-consciousness “Hello World”
> > tutoring for those of us who want to get into Scheme-ing, but real
> > life seems to always get in the way?
> >
> > I’d be happy to pay a little something — in currency hard (€) or soft
> > (suds/grapes) — for the time & expertise.
> >
> > Thanks,
> > Kieren.

Hi Kieren,

my talk would be probably of some interest for you. From the description:
"This talk discusses the prerequisites needed to write LilyPond
extensions. A detailed, commented code example
will be used to demonstrate how to retrieve details of LilyPond’s
internals, how to modify them as necessary for
the task at hand, and how to overcome obstacles, if possible. Finally,
some thoughts will be shared on how to
improve and simplify the coding of extensions in general. Languages:
German and English."

Alas, it will be in german, so I can't imagine how helpful it would be for you.
Werner will likely upload the (german) script. And probably I could be
persuaded to make an english version as well, although this would take
some time.
Though, I don't trust my spoken english enough to do the talk in english.
This would hold for your "bootcamp" as well.

Apart from the problem finding a slot for it, as Urs already
mentioned, such a meeting would be a great place for it. Maybe we can
arrange something more or less ad hoc once we meet there.


Generally I'd be interested where you think the obstacles guile <->
LilyPond are.
I frequently fail to really understand it.
You may have noticed
https://lists.gnu.org/archive/html/lilypond-user/2020-01/msg00154.html
where Daniel replies to my question.
The main point could probably summarized as "confusing doc"

Where do _you_ think are the problems?


Cheers,
  Harm

Savannah push access question

[Dan Eble]

I recently started using a git GUI, GitUp, which sometimes infers that I might 
want to delete origin/staging, and offers to do it for me.  Needless to say, I 
don't want that; and I've suggested in the GitUp issue tracker that even 
prompting me is a defect, in the light of this project's workflow.

My question here is, do I need to maintain extreme caution if I continue using 
this tool?  Would the git server actually delete origin/staging if I hit the 
wrong button by mistake?

Thanks,
— 
Dan

Re: Is the CG out of date?

[Federico Bruni]

Il giorno mar 14 gen 2020 alle 18:21, Peter Toye  
ha scritto:
I'm trying to work out how to run LilyDev in VirtualBox on a Windows 
system., but the information in section 2.1 of the CG seems to be 
inaccurate, and I suspect it's a bit out of date.


Under "Installing LilyDev in VirtualBox" the filename is given as 
lilydev-vm-fedora-VERSION.raw but the downloaded version form the 
website was LilyDev-1-debian-vm.zip


I assume that this is correct, but in that case should I install it 
as Debian rather than Fedora?





Yes, the CG is not up-to-date.
Please follow the README files in Github.

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

[nine . fierce . ballads]

On 2020/01/14 18:21:32, hahnjo wrote:

Dan, if you don't want to run autogen.sh with a writable

~/lilypond-src, maybe

you can instead copy all files from that directory to a fresh one in

the

container?


If this expands to "rsync the latest changes to the build directory
before you build; and if you forget, it builds anyway but your changes
are disregarded," it's unappealing.

If the current little hack threatened to grow into something awful, an
important question to ask would be, "What's the problem with having to
configure before building the website?"  I'm referring to this comment
from early on:


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.



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

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

[nine . fierce . ballads]

Let me try to recount all the factors that did or do contribute to my
liking a read-only source directory.  This is mainly to help me decide
whether to concede this feature, not to elicit any response from you.

Unstable virtualization.  Linux in VirtualBox (which I no longer use) on
macOS did not handle sleeping and waking gracefully.  The time of day in
the guest would get out of sync.  From time to time, the kernel would
panic.  In those days, I was keeping my LilyPond work in a virtual disk
image (VDI), but I didn't want the host to back up the whole multi-GB
VDI file whenever any part of it changed, and I didn't want to jump
through the additional hoops to get the source out of the VDI for
backup.  Instability with no backup gave me the heebie-jeebies.  Now,
with Docker, I store my work on the host, where it is included in
automatic backups.  Docker has been much more stable than VirtualBox
was, though at the time I switched, I carried over some concern that it
might foul up something in my host filesystem if I gave it write access.

Debugging.  When you're debugging a build script, even if you mess
something up, there is no way it can defile or destroy your source files
when they are mounted read-only.  Sure, source control could be used to
recover, but who wants to commit before every test run just in case a
disaster occurs?  A similar case is when you've turned your build
directory into a shambles.  You can simply remove it and be sure that
you've gotten everything; you don't have to sift the source directory
for generated files that might affect your next build.

Storage quotas.  I keep my build directory on a separate partition so
that an unexpected increase in storage requirements will cause the build
to fail rather than infringe on the rest of my space.  I don't want to
keep my source on that limited partition, but I still don't want
programs running in the container to be able to use as much space as
they please in the source directory.

Performance.  Docker access to macOS host files is slow.  (I recall that
`make check` takes 3-4 times as long when the build directory is stored
on the host than when the build directory is in a "Docker volume.")
This would a good reason NOT to store your source on the host, but if
you want to store it on the host for other reasons (e.g. simplified
backup), this IS a good reason to limit the container's access to
reading, because Docker offers the option to cache the host's version of
the files.  I don't recall measuring the impact of caching the source
directory; I've been taking the documentation at its word.

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

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

[thomasmorley65]

On 2020/01/14 17:43:19, Dan Eble wrote:

On 2020/01/14 13:12:54, Dan Eble wrote:
> Harm,
> Do you want more time to consider this change, or are you now

comfortable with

> my pushing it?



Since your primary concern was that modifying Global in a \layout

block should

still work, and my testing shows that it does, I'm going to push this.


Hi Dan,

sorry, wasn't online some time ...

Additionally, I was thinking about:

{
\context Global
\applyContext #(lambda (ctx) ...)
...
}

Though, for which use-cases ...?
I didn't find any.

So I'm fine with the patch being pushed.

Cheers,
  Harm

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

Is the CG out of date?

[Peter Toye]

I'm trying to work out how to run LilyDev in VirtualBox on a Windows system., 
but the information in section 2.1 of the CG seems to be inaccurate, and I 
suspect it's a bit out of date.

Under "Installing LilyDev in VirtualBox" the filename is given as 
lilydev-vm-fedora-VERSION.raw but the downloaded version form the website was 
LilyDev-1-debian-vm.zip 

I assume that this is correct, but in that case should I install it as Debian 
rather than Fedora?
 
Regards,

Peter
mailto:lilyp...@ptoye.com
www.ptoye.com

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

[jonas . hahnfeld]

On 2020/01/14 15:54:28, dak wrote:

Well, how about
diff --git a/autogen.sh b/autogen.sh
index 1ca0fc0c0f..c638993f34 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -18,7 +18,7 @@ else
configure=./configure
conf_flags="--srcdir $srcdir $conf_flags"
echo "Running autoconf for read-only source directory ..."
-  autoconf -I "$srcdir" -o "$configure" "$srcdir/configure.ac" ||

exit 1

+  SRCDIR="$srcdir" autoconf -I "$srcdir" -o "$configure"

"$srcdir/configure.ac"

|| exit 1
  fi
  # Autoconf automatically checks its own minimum required
  # version, and it aborts when the check fails.
diff --git a/configure.ac b/configure.ac
index bdbc827187..c75e01de9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,7 +4,9 @@ dnl Process this file with autoconf to produce a

configure

script.
  AC_PREREQ(2.60)



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

[http://lilypond.org/])


  # Bootstrap StepMake configure
  AC_CONFIG_AUX_DIR([config])



That would seem to cater for Dan's use case reasonably well.  Sure,

calling

autoconf from outside of autogen.sh for a read-only source

directory...  But at

some point of time, people have to deal with the strange things they

do.

IF we really want to continue supporting autoconf in a read-only
directory, then this sounds like one of the few possibilities we have.
I've added this for now (thanks for your testing efforts!), but it will
probably hit us sooner or later...

Dan, if you don't want to run autogen.sh with a writable ~/lilypond-src,
maybe you can instead copy all files from that directory to a fresh one
in the container?

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

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

[nine . fierce . ballads]

On 2020/01/14 13:12:54, Dan Eble wrote:

Harm,
Do you want more time to consider this change, or are you now

comfortable with

my pushing it?


Since your primary concern was that modifying Global in a \layout block
should still work, and my testing shows that it does, I'm going to push
this.


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

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

[dak]

On 2020/01/14 16:35:50, Dan Eble wrote:

On 2020/01/14 15:54:28, dak wrote:
> +AC_INIT([LilyPond],
> +[m4_esyscmd_s([. ${SRCDIR:-.}/VERSION; echo



I was about to test it, but the main patch no longer applies to

master.  I'll

try against an older version.



I do wonder whether someone might see ${SRCDIR} here and use it

elsewhere in the

script.  Would that be a problem?


It would be unrelated.  Definition and use here are while running
autoconf, not while running the resulting configure.  I was considering
using AC_SRCDIR or something like it.  Maybe that would reduce the
temptation to try something that doesn't work.

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

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

[nine . fierce . ballads]

On 2020/01/14 16:35:50, Dan Eble wrote:

On 2020/01/14 15:54:28, dak wrote:
> +AC_INIT([LilyPond],
> +[m4_esyscmd_s([. ${SRCDIR:-.}/VERSION; echo



I was about to test it, but the main patch no longer applies to

master.  I'll

try against an older version.



I do wonder whether someone might see ${SRCDIR} here and use it

elsewhere in the

script.  Would that be a problem?


Over yesterday's master, it works for me.

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

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

[nine . fierce . ballads]

On 2020/01/14 15:54:28, dak wrote:

+AC_INIT([LilyPond],
+[m4_esyscmd_s([. ${SRCDIR:-.}/VERSION; echo


I was about to test it, but the main patch no longer applies to master.
I'll try against an older version.

I do wonder whether someone might see ${SRCDIR} here and use it
elsewhere in the script.  Would that be a problem?


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

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

[dak]

On 2020/01/14 15:19:09, dak wrote:

On 2020/01/14 15:07:48, dak wrote:
> On 2020/01/14 14:48:44, Dan Eble wrote:
> > On 2020/01/14 14:43:34, hahnjo wrote:
> > > On 2020/01/14 14:29:38, Dan Eble wrote:
> > > > On 2020/01/14 13:59:43, dak wrote:
> > > > > On 2020/01/14 13:52:02, hahnjo wrote:
> > > > > I am not overly happy that it makes for inoperative code in

the case

of
> a
> > > > > read-only repository that autogen.sh tries catering for.
> > > >
> > > > Thank you for calling this out, for I was not paying

attention.  I am

> > > currently
> > > > using a read-only view of the source directory in my build

environment.

> > > >
> > > > Please do not push this change yet.  I will review it shortly

and offer

an
> > > > opinion.
> > >
> > > Sure, I'm not in a hurry to land this.
> > > Could you maybe share how your build environment looks like to

use a

> read-only
> > > view of the git repository?
> >
> > I build in a Docker container.  ~/lilypond-src is a read-only view

of the

git
> > source tree.  ~/lilypond-build is the build directory.  This is

how I begin:

> >
> > cd ~/lilypond-build
> > ~/lilypond-src/autogen.sh
>
> I should have checked the "git blame" output.
>
> commit edb80ace4df074fcb8a4976f452aabd2238cf733
> Author: Dan Eble 
> Date:   Sat Jan 27 13:04:49 2018 -0500
>
> Issue 5268: simplify building with a read-only source directory
>
> autogen.sh: If the source directory is not writable, generate

the

> configure script into the current directory and tell the

configure

> script the source directory.
>
> This is convenient for those would prefer to build in a

container or

> virtual machine with a read-only view of source stored on the

host.


Well, the easiest expedience would be putting (on the assumption that

we don't

have to deal with Windows file systems or similar)



ln -sf $srcdir/VERSION .



before the autoconf call.  Making a copy instead of a symbolic link is

also

conceivable but may be more likely to cause problems.  Or one figures

out a

proper solution.  Let me see.


Well, how about
diff --git a/autogen.sh b/autogen.sh
index 1ca0fc0c0f..c638993f34 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -18,7 +18,7 @@ else
   configure=./configure
   conf_flags="--srcdir $srcdir $conf_flags"
   echo "Running autoconf for read-only source directory ..."
-  autoconf -I "$srcdir" -o "$configure" "$srcdir/configure.ac" || exit
1
+  SRCDIR="$srcdir" autoconf -I "$srcdir" -o "$configure"
"$srcdir/configure.ac" || exit 1
 fi
 # Autoconf automatically checks its own minimum required
 # version, and it aborts when the check fails.
diff --git a/configure.ac b/configure.ac
index bdbc827187..c75e01de9b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4,7 +4,9 @@ dnl Process this file with autoconf to produce a
configure script.
 AC_PREREQ(2.60)

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

 # Bootstrap StepMake configure
 AC_CONFIG_AUX_DIR([config])

That would seem to cater for Dan's use case reasonably well.  Sure,
calling autoconf from outside of autogen.sh for a read-only source
directory...  But at some point of time, people have to deal with the
strange things they do.

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

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

[dak]

On 2020/01/14 15:07:48, dak wrote:

On 2020/01/14 14:48:44, Dan Eble wrote:
> On 2020/01/14 14:43:34, hahnjo wrote:
> > On 2020/01/14 14:29:38, Dan Eble wrote:
> > > On 2020/01/14 13:59:43, dak wrote:
> > > > On 2020/01/14 13:52:02, hahnjo wrote:
> > > > I am not overly happy that it makes for inoperative code in

the case of

a
> > > > read-only repository that autogen.sh tries catering for.
> > >
> > > Thank you for calling this out, for I was not paying attention.

I am

> > currently
> > > using a read-only view of the source directory in my build

environment.

> > >
> > > Please do not push this change yet.  I will review it shortly

and offer an

> > > opinion.
> >
> > Sure, I'm not in a hurry to land this.
> > Could you maybe share how your build environment looks like to use

a

read-only
> > view of the git repository?
>
> I build in a Docker container.  ~/lilypond-src is a read-only view

of the git

> source tree.  ~/lilypond-build is the build directory.  This is how

I begin:

>
> cd ~/lilypond-build
> ~/lilypond-src/autogen.sh



I should have checked the "git blame" output.



commit edb80ace4df074fcb8a4976f452aabd2238cf733
Author: Dan Eble 
Date:   Sat Jan 27 13:04:49 2018 -0500



 Issue 5268: simplify building with a read-only source directory



 autogen.sh: If the source directory is not writable, generate the
 configure script into the current directory and tell the configure
 script the source directory.



 This is convenient for those would prefer to build in a container

or

 virtual machine with a read-only view of source stored on the

host.

Well, the easiest expedience would be putting (on the assumption that we
don't have to deal with Windows file systems or similar)

ln -sf $srcdir/VERSION .

before the autoconf call.  Making a copy instead of a symbolic link is
also conceivable but may be more likely to cause problems.  Or one
figures out a proper solution.  Let me see.

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

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

[nine . fierce . ballads]

Jonas,
If you want to push this in a form where the only thing lacking is to
copy VERSION to the build directory, I am willing to test and submit a
patch to autogen.sh.

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

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

[dak]

On 2020/01/14 14:48:44, Dan Eble wrote:

On 2020/01/14 14:43:34, hahnjo wrote:
> On 2020/01/14 14:29:38, Dan Eble wrote:
> > On 2020/01/14 13:59:43, dak wrote:
> > > On 2020/01/14 13:52:02, hahnjo wrote:
> > > I am not overly happy that it makes for inoperative code in the

case of a

> > > read-only repository that autogen.sh tries catering for.
> >
> > Thank you for calling this out, for I was not paying attention.  I

am

> currently
> > using a read-only view of the source directory in my build

environment.

> >
> > Please do not push this change yet.  I will review it shortly and

offer an

> > opinion.
>
> Sure, I'm not in a hurry to land this.
> Could you maybe share how your build environment looks like to use a

read-only

> view of the git repository?



I build in a Docker container.  ~/lilypond-src is a read-only view of

the git

source tree.  ~/lilypond-build is the build directory.  This is how I

begin:


 cd ~/lilypond-build
 ~/lilypond-src/autogen.sh


I should have checked the "git blame" output.

commit edb80ace4df074fcb8a4976f452aabd2238cf733
Author: Dan Eble 
Date:   Sat Jan 27 13:04:49 2018 -0500

Issue 5268: simplify building with a read-only source directory

autogen.sh: If the source directory is not writable, generate the
configure script into the current directory and tell the configure
script the source directory.

This is convenient for those would prefer to build in a container or
virtual machine with a read-only view of source stored on the host.


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

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

[nine . fierce . ballads]

On 2020/01/14 14:43:34, hahnjo wrote:

On 2020/01/14 14:29:38, Dan Eble wrote:
> On 2020/01/14 13:59:43, dak wrote:
> > On 2020/01/14 13:52:02, hahnjo wrote:
> > I am not overly happy that it makes for inoperative code in the

case of a

> > read-only repository that autogen.sh tries catering for.
>
> Thank you for calling this out, for I was not paying attention.  I

am

currently
> using a read-only view of the source directory in my build

environment.

>
> Please do not push this change yet.  I will review it shortly and

offer an

> opinion.



Sure, I'm not in a hurry to land this.
Could you maybe share how your build environment looks like to use a

read-only

view of the git repository?


I build in a Docker container.  ~/lilypond-src is a read-only view of
the git source tree.  ~/lilypond-build is the build directory.  This is
how I begin:

cd ~/lilypond-build
~/lilypond-src/autogen.sh


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

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

[jonas . hahnfeld]

On 2020/01/14 14:29:38, Dan Eble wrote:

On 2020/01/14 13:59:43, dak wrote:
> On 2020/01/14 13:52:02, hahnjo wrote:
> I am not overly happy that it makes for inoperative code in the case

of a

> read-only repository that autogen.sh tries catering for.



Thank you for calling this out, for I was not paying attention.  I am

currently

using a read-only view of the source directory in my build

environment.


Please do not push this change yet.  I will review it shortly and

offer an

opinion.


Sure, I'm not in a hurry to land this.
Could you maybe share how your build environment looks like to use a
read-only view of the git repository?

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

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

[dak]

On 2020/01/14 14:12:47, hahnjo wrote:

On 2020/01/14 13:59:43, dak wrote:
> On 2020/01/14 13:52:02, hahnjo wrote:
> > Is this ok to push in its current revision?
>
> I am not overly happy that it makes for inoperative code in the case

of a

> read-only repository that autogen.sh tries catering for.  Can/should
autogen.sh
> pass some sort of environment variable that this can be picked up

from in the

> shell code executed for getting the version number?  Or is this

available in

> some m4 variable one could pick up?



As autoconf itself doesn't handle this case, I doubt there is a good

solution.


> Maybe at least stick a #FIXIT comment into autogen.sh (and possibly
> configure.ac) so that someone bumping into this has less trouble

figuring out

> what went wrong?



Sure can do. If nobody complains, maybe we could even consider

dropping support

for autogen'ing a readonly source directory?


Well, it seems like making it inoperative and sticking FIXITs in there
is less of a clear signal (and possibly less likely to garner notice we
can react to) than it just failing to cater for it, and with version
control one can always resuscitate code that went absent.

So maybe just remove the code.  Or wait, you can replace

  configure=./configure
  conf_flags="--srcdir $srcdir $conf_flags"
  echo "Running autoconf for read-only source directory ..."
  autoconf -I "$srcdir" -o "$configure" "$srcdir/configure.ac" || exit 1

with

  echo "Running autoconf for read-only source directory not supported"

&2

  exit 1

and if someone complains, we can still think how to fix it.  The
simplest version likely just being copying the VERSION file over before
running autoconf.  But before we install patchwork like that, let
someone complain that they were actually using the code.

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

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

[nine . fierce . ballads]

On 2020/01/14 13:59:43, dak wrote:

On 2020/01/14 13:52:02, hahnjo wrote:
I am not overly happy that it makes for inoperative code in the case

of a

read-only repository that autogen.sh tries catering for.


Thank you for calling this out, for I was not paying attention.  I am
currently using a read-only view of the source directory in my build
environment.

Please do not push this change yet.  I will review it shortly and offer
an opinion.


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

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

[jonas . hahnfeld]

On 2020/01/14 13:59:43, dak wrote:

On 2020/01/14 13:52:02, hahnjo wrote:
> Is this ok to push in its current revision?



I am not overly happy that it makes for inoperative code in the case

of a

read-only repository that autogen.sh tries catering for.  Can/should

autogen.sh

pass some sort of environment variable that this can be picked up from

in the

shell code executed for getting the version number?  Or is this

available in

some m4 variable one could pick up?


As autoconf itself doesn't handle this case, I doubt there is a good
solution.


Maybe at least stick a #FIXIT comment into autogen.sh (and possibly
configure.ac) so that someone bumping into this has less trouble

figuring out

what went wrong?


Sure can do. If nobody complains, maybe we could even consider dropping
support for autogen'ing a readonly source directory?

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

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

[dak]

On 2020/01/14 13:52:02, hahnjo wrote:

Is this ok to push in its current revision?


I am not overly happy that it makes for inoperative code in the case of
a read-only repository that autogen.sh tries catering for.  Can/should
autogen.sh pass some sort of environment variable that this can be
picked up from in the shell code executed for getting the version
number?  Or is this available in some m4 variable one could pick up?

Maybe at least stick a #FIXIT comment into autogen.sh (and possibly
configure.ac) so that someone bumping into this has less trouble
figuring out what went wrong?

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

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

[jonas . hahnfeld]

Is this ok to push in its current revision?

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

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

[nine . fierce . ballads]

Harm,
Do you want more time to consider this change, or are you now
comfortable with my pushing it?
--
Dan


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

PATCHES - Countdown for January 14th

[James]

 Hello,

 Here is the current patch countdown list. The next countdown will be on
 January 16th.

 A quick synopsis of all patches currently in the review process can be
 found here:

http://philholmes.net/lilypond/allura/ [1]

 

PUSH:

5657 Remove vestiges of support for systems without - Dan Eble
 https://sourceforge.net/p/testlilyissues/issues/5657 [2]
http://codereview.appspot.com/553350043 [3] 

5656 Warn about accessing the Global context explicitly - Dan Eble
 https://sourceforge.net/p/testlilyissues/issues/5656 [4]
http://codereview.appspot.com/567050043 [5] 

5655 general-column entirely drops empty stencils - Thomas Morley
 https://sourceforge.net/p/testlilyissues/issues/5655 [6]
http://codereview.appspot.com/567060043 [7] 

5654 Cleanup initialization of configure process - Jonas Hahnfeld
 https://sourceforge.net/p/testlilyissues/issues/5654 [8]
http://codereview.appspot.com/549350043 [9] 

5653 Cleanup unneeded parts of Stepmake - Jonas Hahnfeld
 https://sourceforge.net/p/testlilyissues/issues/5653 [10]
http://codereview.appspot.com/577280043 [11] 

5601 Changes.tely (2.20): afterGrace command got an optional argument
that should be documented - James Lowe
 https://sourceforge.net/p/testlilyissues/issues/5601 [12]
http://codereview.appspot.com/551260043 [13] 

COUNTDOWN:

5658 Include consistently, not - Dan Eble
 https://sourceforge.net/p/testlilyissues/issues/5658 [14]
http://codereview.appspot.com/569220043 [15] 

5652 Fix a few complaints in python/convertrules.py - David Kastrup
 https://sourceforge.net/p/testlilyissues/issues/5652 [16]
http://codereview.appspot.com/583290043 [17] 

5309 find_score_context () and find_global_context () - Dan Eble
 https://sourceforge.net/p/testlilyissues/issues/5309 [18]
http://codereview.appspot.com/561290043 [19] 

REVIEW:

5659 Clean up to_string () etc. - Dan Eble
 https://sourceforge.net/p/testlilyissues/issues/5659 [20]
http://codereview.appspot.com/583320043 [21] 

NEW:

5661 Fix some conversion warnings in Source_file. - Dan Eble
 https://sourceforge.net/p/testlilyissues/issues/5661 [22]
http://codereview.appspot.com/567090043 [23] 

5660 Doc: Added documentation for fill-line line-width - davidsg
 https://sourceforge.net/p/testlilyissues/issues/5660 [24]
http://codereview.appspot.com/583340043 [25] 

 ***

 Regards,

 James

 

Links:
--
[1] http://philholmes.net/lilypond/allura/
[2] https://sourceforge.net/p/testlilyissues/issues/5657
[3] http://codereview.appspot.com/553350043
[4] https://sourceforge.net/p/testlilyissues/issues/5656
[5] http://codereview.appspot.com/567050043
[6] https://sourceforge.net/p/testlilyissues/issues/5655
[7] http://codereview.appspot.com/567060043
[8] https://sourceforge.net/p/testlilyissues/issues/5654
[9] http://codereview.appspot.com/549350043
[10] https://sourceforge.net/p/testlilyissues/issues/5653
[11] http://codereview.appspot.com/577280043
[12] https://sourceforge.net/p/testlilyissues/issues/5601
[13] http://codereview.appspot.com/551260043
[14] https://sourceforge.net/p/testlilyissues/issues/5658
[15] http://codereview.appspot.com/569220043
[16] https://sourceforge.net/p/testlilyissues/issues/5652
[17] http://codereview.appspot.com/583290043
[18] https://sourceforge.net/p/testlilyissues/issues/5309
[19] http://codereview.appspot.com/561290043
[20] https://sourceforge.net/p/testlilyissues/issues/5659
[21] http://codereview.appspot.com/583320043
[22] https://sourceforge.net/p/testlilyissues/issues/5661
[23] http://codereview.appspot.com/567090043
[24] https://sourceforge.net/p/testlilyissues/issues/5660
[25] http://codereview.appspot.com/583340043