Subject: bug#75655: configure doesn't update Makefile

From: Pip Cet <[email-masked]>
Date: Fri, 24 Jan 2025 13:14:26 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> Date: Thu, 23 Jan 2025 20:10:44 +0000
>> From: Pip Cet <[email-masked]>
>> Cc: Eli Zaretskii <[email-masked]>, [email-masked], [email-masked]
>>
>> --- a/INSTALL.REPO
>> +++ b/INSTALL.REPO
>> @@ -75,18 +75,19 @@ To rebuild Emacs with the default configuration options, you can use:
>>
>>    $ make bootstrap configure=default
>>
>> -Occasionally, there are changes that 'make bootstrap' won't be able to
>> -handle.  The most thorough cleaning can be achieved by 'git clean -fdx'
>> -which will leave you with only files from the git repository.  Here
>> -are some faster methods for a couple of particular error cases:
>> +Rarely, after a git update, all 'make' commands will fail because the
>> +Makefile itself is no longer usable.  Error messages such as:
>>
>> -    /usr/bin/m4:aclocal.m4:9: cannot open `m4/stdbit_h.m4': No such file or directory
>> +    make: *** No rule to make target 'benchmarks/Makefile.in', needed by 'Makefile'.  Stop.
>>
>> -This can be fixed with 'rm aclocal.m4'.
>> +indicate this.  You should delete and rebuild the Makefile:
>>
>> -    make: *** No rule to make target 'lib/Makefile.am', needed by 'lib/Makefile.in'
>> +  $ rm -f Makefile
>> +  $ make
>> +
>> +If this doesn't fix the problem, you can clean the git repo:
>>
>> -This can be fixed with 'rm lib/Makefile Makefile'.
>> +  $ git clean -idX
>
> IMO, this loses useful information about the aclocal.m4 problem.  It

My understanding is this problem was fixed long ago (see below!), when
this rule was changed to include a $(wildcard) (later replaced by a
simple glob, which makes the code less readable and seem obviously
incorrect to the casual reader):

$(srcdir)/configure: $(srcdir)/configure.ac $(srcdir)/m4/*.m4
	cd $(srcdir) && ./autogen.sh autoconf

Even if I'm wrong about that, I expected the reader to try the "git
clean -idX" trick anyway, which should help.  However, I now suggest
replacing "fix the problem" by "fix this or similar problems" to make it
more likely the reader will try the second fix rather than rm -rf emacs.

In summary:

1. definitely fixed now
2. fixed so long ago it won't break 'git bisect' anymore
3. if it does break, we'll still be covered

> was there because it happened to people, and users who are not experts
> in Automake will have trouble coping with it.  I do agree that it
> should be very rare, so making it the last problem we describe is
> okay.

The command to build aclocal.m4 (in autogen.sh) was changed to use
wildcards, and the Makefile.in rule to rerun autogen.sh autoconf also
uses wildcards.

> Moving "git -fdx" to the end and changing it to "git -idx" is also a

It doesn't make sense to tell people to try the more drastic solution
first, then suggest they might get away with a less drastic and more
dangerous solution afterwards.

Specifying a --force option and abbreviating it so it isn't obvious that
something is being forced that the Git authors did not think should
happen by default is a mistake, IMHO.  Developers will refuse to specify
--force, I would hope.

> mistake, IMO.  It is a much simpler operation to do, and cannot
> possibly mistakenly delete required files.  In a clean tree, it is
> also TRT.  I'm okay with Stefan's suggestion to explain that this

In an unclean tree, "git clean" won't revert uncommitted changes in
files that DO exist in the base version.  An additional git reset is
required for that.

> command removes uncommitted changes, and saying that if there are
> uncommitted changes one wants to keep, one should use the interactive
> "git -idx" instead.  But let's not spare the important details;

The problem is that when I said "uncommitted changes", I was referring
to new files.  People will not expect a new lisp file they're working on
to be permanently removed if they previously ran a command to identify
"uncommitted changes", which usually skips new files.

> instead, let's describe them, along with the supporting information
> that would allow people to make informed decisions what to do in their
> particular case.

I don't think INSTALL.REPO is the right place for even more text.

> The text about removing Makefile's should also be amended to explain
> that the Makefile file to be removed is in the directory spelled out
> by the error message.

The intention was that the user would run

  $ rm -f Makefile

in the emacs directory.  What you're saying sounds like

  $ rm -f benchmarks/Makefile

which wouldn't do anything.

> The lib/Makefile.am example was better for that

We switched from automake long ago :-)

> because it included a directory name, but we should amend the text to
> say explicitly that the Makefile to be deleted is in the same
> directory.

The Makefile to be deleted is the one in the emacs/ directory.  Nothing
should be done in the benchmarks/ directory, which doesn't exist at this
point.

> Last, but not least: if we are going to expand INSTALL.REPO to include
> a significant amount of additional information for special cases, we

I ensured my change added no text overall.

> should consider dividing it into sections.  The first section should
> just show the nominal sequence of commands to build Emacs, because
> that's what the absolute majority of readers will need.  The rest
> should have appropriate headings, to allow finding the required
> information easily and quickly.  For example, the part we are
> discussing here could have a heading like "If you encounter a build
> failure" or something to that effect.

Adding more text to INSTALL.REPO in an attempt to structure it seems a
separate issue.

I'm okay with removing the "rm -f Makefile" trick, particularly if we
make it unnecessary for future generations by using $(wildcard) in
Makefile.in.

Pip