bug#25359: autoreconf no longer suffices

bug#25359: autoreconf no longer suffices

[Glenn Morris]

Package: emacs
Version: 26.0.50

After cloning a fresh Emacs, one used to be able to do:

  autoreconf -fi -I m4

then configure etc.

In current master, this no longer works:

  automake: error: cannot open < lib/../nt/gnulib.mk: No such file or directory
  autoreconf: automake failed with exit status: 1

I think it is wrong to make autogen.sh compulsory in this way.

(Obviously the missing file is irrelevant anyway on non MS-Windows
platforms.)

bug#25359: autoreconf no longer suffices

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 04 Jan 2017 14:36:16 -0500
> 
> After cloning a fresh Emacs, one used to be able to do:
> 
>   autoreconf -fi -I m4
> 
> then configure etc.
> 
> In current master, this no longer works:
> 
>   automake: error: cannot open < lib/../nt/gnulib.mk: No such file or directory
>   autoreconf: automake failed with exit status: 1
> 
> I think it is wrong to make autogen.sh compulsory in this way.

Why do you think it's wrong?

> (Obviously the missing file is irrelevant anyway on non MS-Windows
> platforms.)

Evidently, it isn't irrelevant, otherwise the error would have never
happened, right?

bug#25359: autoreconf no longer suffices

[Glenn Morris]

Eli Zaretskii wrote:

>> I think it is wrong to make autogen.sh compulsory in this way.
>
> Why do you think it's wrong?

Perhaps it's just my opinion. It was the original intent of autogen.sh
to be just a convenience wrapper for sanity checks + autoreconf.

If this is no longer true, here are some places that need to be changed:

1) autogen.sh error output says: "If you know that the required versions
are in your PATH, but this script has made an error, then you can simply
run autoreconf -fi -I m4 instead of this script."

(INSTALL.REPO used to say this too, before the IMO unrelated a3f989d
removed it.)

2) make-dist with update=yes uses autoreconf

3) top-level Makefile needs updating as per bug#25372

4) autogen.sh should ensure the outputs are newer than the inputs.
nt/gnulib.mk is only tested for existence, not freshness.
Since we use autoreconf -f, I think you can simply unconditionally
create nt/gnulib.mk every time.

All in all, it would make lifer simpler if plain automake would still
work, but I can see it might be difficult to implement.

>> (Obviously the missing file is irrelevant anyway on non MS-Windows
>> platforms.)
>
> Evidently, it isn't irrelevant, otherwise the error would have never
> happened, right?

Eg "touch nt/gnulib.mk" works just as well on non-MS platforms, where
the contents of the file are completely irrelevant.

bug#25359: autoreconf no longer suffices

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 25359@debbugs.gnu.org
> Date: Fri, 06 Jan 2017 13:13:49 -0500
> 
> Eli Zaretskii wrote:
> 
> >> I think it is wrong to make autogen.sh compulsory in this way.
> >
> > Why do you think it's wrong?
> 
> Perhaps it's just my opinion. It was the original intent of autogen.sh
> to be just a convenience wrapper for sanity checks + autoreconf.

AFAIR, many packages I've built require running autogen.sh as the
first step, which I interpret as a de-facto standard.  Perhaps that's
just my misperception.

> 4) autogen.sh should ensure the outputs are newer than the inputs.
> nt/gnulib.mk is only tested for existence, not freshness.

The freshness is ensured by Makefile's.  But to have Makefile's
generated we must have this file, because autoreconf needs it.

> >> (Obviously the missing file is irrelevant anyway on non MS-Windows
> >> platforms.)
> >
> > Evidently, it isn't irrelevant, otherwise the error would have never
> > happened, right?
> 
> Eg "touch nt/gnulib.mk" works just as well on non-MS platforms, where
> the contents of the file are completely irrelevant.

The problem is not the command that generates the file, the problem is
where to put it and how to make sure it runs before Automake, because
it's Automake that needs it.  If you can find a way to run the 'touch'
command, we can run the full Sed command in the same place and manner.