Cleanup initialization of configure process

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. Call AC_INIT correctly with all parameters

Version information via m4_esyscmd() by David K.

4. Remove passing of package variables

[dak, 2020-01-08 16:18:25]

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-lilypond@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?

[hahnjo, 2020-01-08 16:22:32]

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-lilypond@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.

[dak, 2020-01-08 16:43:24]

jonas.hahnfeld@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-lilypond@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

[hahnjo, 2020-01-08 17:48:36]

On 2020/01/08 16:43:24, dak wrote:
> mailto:jonas.hahnfeld@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-lilypond@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.

[dak, 2020-01-08 18:03:36]

On 2020/01/08 17:48:36, hahnjo wrote:
> On 2020/01/08 16:43:24, dak wrote:
> > mailto:jonas.hahnfeld@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-lilypond@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-lilypond@gnu.org],
[lilypond], [http://lilypond.org/])

work?

[hahnjo, 2020-01-08 18:09:53]

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.hahnfeld@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-lilypond@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-lilypond@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')

[hahnjo, 2020-01-08 18:10:50]

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.hahnfeld@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-lilypond@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-lilypond@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.

[dak, 2020-01-08 18:48:10]

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-lilypond@gnu.org],
> [lilypond], [http://lilypond.org/])
> 
> work?

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

[c_sorensen, 2020-01-08 19:40:06]

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 dak@gnu.org"
<lilypond-devel-bounces+c_sorensen=byu.edu@gnu.org on behalf of dak@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-lilypond@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/
    
    

[hahnjo, 2020-01-08 19:49:22]

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

[dak, 2020-01-08 20:14:20]

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-lilypond@gnu.org], [lilypond], [http://lilypond.org/])

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

[c_sorensen, 2020-01-08 20:15:10]

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/Initiali...

"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.hahnfeld@gmail.com" <jonas.hahnfeld@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/
    

[hahnjo, 2020-01-08 20:30:20]

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-lilypond@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...

[c_sorensen, 2020-01-08 20:39:05]

On 1/8/20, 1:30 PM, "jonas.hahnfeld@gmail.com" <jonas.hahnfeld@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!

 

[dak, 2020-01-08 20:46:37]

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-lilypond@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...

[hahnjo, 2020-01-08 21:08:58]

Take information from VERSION

[hahnjo, 2020-01-08 21:11:00]

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-lilypond@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...

[hahnjo, 2020-01-14 13:52:02]

Is this ok to push in its current revision?

[dak, 2020-01-14 13:59:43]

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?

[hahnjo, 2020-01-14 14:12:47]

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?

[Dan Eble, 2020-01-14 14:29:38]

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.

[dak, 2020-01-14 14:37:21]

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.

[hahnjo, 2020-01-14 14:43:34]

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?

[Dan Eble, 2020-01-14 14:48:44]

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

[dak, 2020-01-14 15:07:48]

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 <nine.fierce.ballads@gmail.com>
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.

[Dan Eble, 2020-01-14 15:08:59]

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.

[dak, 2020-01-14 15:19:09]

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 <mailto:nine.fierce.ballads@gmail.com>
> 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.

[dak, 2020-01-14 15:54:28]

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 <mailto:nine.fierce.ballads@gmail.com>
> > 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-lilypond@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.

[Dan Eble, 2020-01-14 16:35:50]

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?

[Dan Eble, 2020-01-14 16:59:52]

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.

[dak, 2020-01-14 17:20:53]

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.

[hahnjo, 2020-01-14 18:14:56]

Workaround for read-only source directories

[hahnjo, 2020-01-14 18:21:32]

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-lilypond@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?

[Dan Eble, 2020-01-14 20:10:34]

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.

[Dan Eble, 2020-01-14 21:56:24]

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.

[hahnjo, 2020-01-15 08:08:26]

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.

[dan_faithful.be, 2020-01-15 13:50:29]

On Jan 15, 2020, at 03:08, jonas.hahnfeld@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

[hahnjo, 2020-01-15 14:00:15]

On 2020/01/15 13:50:29, dan_faithful.be wrote:
> On Jan 15, 2020, at 03:08, mailto:jonas.hahnfeld@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.

[dan_faithful.be, 2020-01-15 14:36:29]

On Jan 15, 2020, at 09:00, jonas.hahnfeld@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

[hahnjo, 2020-01-16 08:38:30]

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

[dak, 2020-01-16 10:57:46]

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?

[hahnjo, 2020-01-16 11:22:24]

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?

[dak, 2020-01-16 13:24:21]

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 <<EOF
          $foo
          EOF

     Alternatively, M4sh provides 'AS_ECHO' and 'AS_ECHO_N' macros which
     choose between various portable implementations: 'echo' or 'print'
     where they work, 'printf' if it is available, or else other
     creative tricks in order to work around the above problems.

[hahnjo, 2020-01-16 16:06:47]

Use m4_esyscmd_s + echo without -n

[Dan Eble, 2020-01-17 07:35:45]

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.

[hahnjo, 2020-01-17 08:12:06]

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.