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

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

David Kastrup

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], [[hidden email]],
[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/

Reply | Threaded
Open this post in threaded view
|

Re: Cleanup initialization of configure process (issue 549350043 by jonas.hahnfeld@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:[[hidden email]],
> [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



Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
[hidden email] 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:[[hidden email]],
>> [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

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
On 2020/01/08 16:43:24, dak wrote:
> mailto:[hidden email] 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:[[hidden email]],
> >> [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/

Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by David Kastrup
On 2020/01/08 17:48:36, hahnjo wrote:
> On 2020/01/08 16:43:24, dak wrote:
> > mailto:[hidden email] 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:[[hidden email]],
> > >> [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:[[hidden email]], [lilypond], [http://lilypond.org/])

work?

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

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
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:[hidden email] 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:[[hidden email]],
> > > >> [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:[[hidden email]],
> [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/

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
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:[hidden email] 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:[[hidden email]],
> > > > >> [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:[[hidden email]],
> > [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/

Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by David Kastrup
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:[[hidden email]],
> [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/

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen-3
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 [hidden email]" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> 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:[[hidden email]],
    > [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/
   
   

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
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/

Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by David Kastrup
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:[[hidden email]], [lilypond], [http://lilypond.org/])

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

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

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen-3
In reply to this post by jonas.hahnfeld
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, "[hidden email]" <[hidden email]> 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/
   

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
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:[[hidden email]], [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/

Reply | Threaded
Open this post in threaded view
|

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

Carl Sorensen-3


On 1/8/20, 1:30 PM, "[hidden email]" <[hidden email]> 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!

 

Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by David Kastrup
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:[[hidden email]], [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/

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
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:[[hidden email]], [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/

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
Is this ok to push in its current revision?

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

Reply | Threaded
Open this post in threaded view
|

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

David Kastrup
In reply to this post by David Kastrup
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/

Reply | Threaded
Open this post in threaded view
|

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

jonas.hahnfeld
In reply to this post by David Kastrup
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/

Reply | Threaded
Open this post in threaded view
|

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

nine.fierce.ballads
In reply to this post by David Kastrup
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/

123