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

[jonas . hahnfeld]

On 2020/01/17 07:35:45, Dan Eble wrote:

I've run some builds with a writable source directory, and I'm fine

with it.

Feel free to move forward with the cleaner change.  I'll submit a

LilyDev pull

request to cope with it.


I'm not going to change this patch once more. We can keep it in mind for
future changes though.

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

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

[nine . fierce . ballads]

I've run some builds with a writable source directory, and I'm fine with
it.  Feel free to move forward with the cleaner change.  I'll submit a
LilyDev pull request to cope with it.

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

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

[dak]

On 2020/01/16 11:22:24, hahnjo wrote:

On 2020/01/16 10:57:46, dak wrote:
> https://codereview.appspot.com/549350043/diff/545440043/configure.ac
> File configure.ac (right):
>
>

https://codereview.appspot.com/549350043/diff/545440043/configure.ac#newcode8

> configure.ac:8: [m4_esyscmd([. ${SRCDIR:-.}/VERSION; echo -n
> $MAJOR_VERSION.$MINOR_VERSION.$PATCH_LEVEL])],
> The proposal using m4_esyscmd_s allowed to use echo without -n

option (which

is
> a bit of a portability thing).  Was there a reason not to take it?



I didn't notice that you changed this and just took the changes with

SRCDIR. But

is there an actual advantage of using m4_esyscmd_s?


The bit of a portability thing?  From the autoconf documentation:

'echo'
 The simple 'echo' is probably the most surprising source of
 portability troubles.  It is not possible to use 'echo' portably
 unless both options and escape sequences are omitted.  Don't expect
 any option.

 Do not use backslashes in the arguments, as there is no consensus
 on their handling.  For 'echo '\n' | wc -l', the 'sh' of Solaris
 outputs 2, but Bash and Zsh (in 'sh' emulation mode) output 1.  The
 problem is truly 'echo': all the shells understand ''\n'' as the
 string composed of a backslash and an 'n'.  Within a command
 substitution, 'echo 'string\c'' will mess up the internal state of
 ksh88 on AIX 6.1 so that it will print the first character 's'
 only, followed by a newline, and then entirely drop the output of
 the next echo in a command substitution.

 Because of these problems, do not pass a string containing
 arbitrary characters to 'echo'.  For example, 'echo "$foo"' is safe
 only if you know that FOO's value cannot contain backslashes and
 cannot start with '-'.

 If this may not be true, 'printf' is in general safer and easier to
 use than 'echo' and 'echo -n'.  Thus, scripts where portability is
 not a major concern should use 'printf '%s\n'' whenever 'echo'
 could fail, and similarly use 'printf %s' instead of 'echo -n'.
 For portable shell scripts, instead, it is suggested to use a
 here-document like this:

  cat 

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

[jonas . hahnfeld]

On 2020/01/16 10:57:46, dak wrote:

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



https://codereview.appspot.com/549350043/diff/545440043/configure.ac#newcode8

configure.ac:8: [m4_esyscmd([. ${SRCDIR:-.}/VERSION; echo -n
$MAJOR_VERSION.$MINOR_VERSION.$PATCH_LEVEL])],
The proposal using m4_esyscmd_s allowed to use echo without -n option

(which is

a bit of a portability thing).  Was there a reason not to take it?


I didn't notice that you changed this and just took the changes with
SRCDIR. But is there an actual advantage of using m4_esyscmd_s?

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

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

[dak]

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

https://codereview.appspot.com/549350043/diff/545440043/configure.ac#newcode8
configure.ac:8: [m4_esyscmd([. ${SRCDIR:-.}/VERSION; echo -n
$MAJOR_VERSION.$MINOR_VERSION.$PATCH_LEVEL])],
The proposal using m4_esyscmd_s allowed to use echo without -n option
(which is a bit of a portability thing).  Was there a reason not to take
it?

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

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

[jonas . hahnfeld]

Assuming no further comments, I'm planning to push this later today
(evening CET).

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

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

[Dan Eble]

On Jan 15, 2020, at 09:00, jonas.hahnf...@gmail.com wrote:
> What's causing problems is that the configure (and only that)
> usually lives in the source directory. In fact, I think you can make the
> source directory read-only right after running autoconf, everything else
> should only touch the build directory.

Well, plan to commit the ugly little hack; however, I will experiment with this 
if I have time.
— 
Dan

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

[jonas . hahnfeld]

On 2020/01/15 13:50:29, dan_faithful.be wrote:

On Jan 15, 2020, at 03:08, mailto:jonas.hahnf...@gmail.com wrote:
>
> Maybe I misunderstood your process; aren't you firing up a fresh
> container for every build?



No, I leave the container running, open an interactive shell into it,

and use it

for a relatively long time.  It is quite like how a VM would be used,

but the

container holds just the tools required for building, testing, and

debugging.

Tasks like source control and editing occur on the host.



> Just as a thought, then you
> could run autogen.sh once on the host in the beginning (or have a

second

> container that is allowed to write, but only runs autoconf).



I couldn't run autoconf on the host, because autoconf is not installed

on the

host.
I could define a second service with write access for running

autoconf.


But is the root of this problem write permission, or separate source

and build

directories?  Allowing writing to my source tree is something I am

willing to

consider.  Storing 4GB of build output in my source tree is something

I have

good reasons (mentioned earlier) to resist.


The first: I also have separate a build directory (even multiple for the
same source directory if needed). You can just execute configure from a
different directory, I also do this for most other software that I'm
building. What's causing problems is that the configure (and only that)
usually lives in the source directory. In fact, I think you can make the
source directory read-only right after running autoconf, everything else
should only touch the build directory.

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

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

[Dan Eble]

On Jan 15, 2020, at 03:08, jonas.hahnf...@gmail.com wrote:
> 
> Maybe I misunderstood your process; aren't you firing up a fresh
> container for every build?

No, I leave the container running, open an interactive shell into it, and use 
it for a relatively long time.  It is quite like how a VM would be used, but 
the container holds just the tools required for building, testing, and 
debugging.  Tasks like source control and editing occur on the host.

> Just as a thought, then you
> could run autogen.sh once on the host in the beginning (or have a second
> container that is allowed to write, but only runs autoconf).

I couldn't run autoconf on the host, because autoconf is not installed on the 
host.
I could define a second service with write access for running autoconf.

But is the root of this problem write permission, or separate source and build 
directories?  Allowing writing to my source tree is something I am willing to 
consider.  Storing 4GB of build output in my source tree is something I have 
good reasons (mentioned earlier) to resist.

> I can
> probably live with the found solution for now, let's see how often it
> causes headaches in the future.

It doesn't seem like the kind of problem that would tend to multiply.

> As my comment already hints to, I'm all in favor to drop (at the least
> the current version number from) VERSION. I have a patch or two that get
> rid of some scripts that rely on VERSION and instead use files generated
> by configure. However I don't understand what "make website" does and
> how it is used in production right now, so the file is not going away in
> the next days. But that's not really the topic of this patch.

I agree that it's wise to avoid disturbing `make website` for now.  My point is 
that, if revising `make website` might eliminate the need for the kludge, then 
it is premature to require me to change my build environment.  I'm not asking 
you to understand it all now, but to understand it before asking me to cope 
with it.  I'm glad to hear that you are willing to live with the kluge for now.
— 
Dan

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

[jonas . hahnfeld]

On 2020/01/14 21:56:24, Dan Eble wrote:

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.


Maybe I misunderstood your process; aren't you firing up a fresh
container for every build? If you're still doing incremental builds,
then this suggestion doesn't work obviously. Just as a thought, then you
could run autogen.sh once on the host in the beginning (or have a second
container that is allowed to write, but only runs autoconf).
But anyway, I'm not going to continue reasoning about an environment
that is so distrustful to any script that could do bad things. I can
probably live with the found solution for now, let's see how often it
causes headaches in the future.


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.


As my comment already hints to, I'm all in favor to drop (at the least
the current version number from) VERSION. I have a patch or two that get
rid of some scripts that rely on VERSION and instead use files generated
by configure. However I don't understand what "make website" does and
how it is used in production right now, so the file is not going away in
the next days. But that's not really the topic of this patch.

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 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: 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: 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: 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: 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: 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)

[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]

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)

[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)

[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: 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)

[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: 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: 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)

[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 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)

[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

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

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/