Package: emacs;
Reported by: Pip Cet <pipcet <at> protonmail.com>
Date: Sat, 18 Jan 2025 19:37:02 UTC
Severity: minor
View this message in rfc822 format
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: schwab <at> linux-m68k.org, stefankangas <at> gmail.com, 75655 <at> debbugs.gnu.org Subject: bug#75655: configure doesn't update Makefile Date: Fri, 24 Jan 2025 13:14:26 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes: >> Date: Thu, 23 Jan 2025 20:10:44 +0000 >> From: Pip Cet <pipcet <at> protonmail.com> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, schwab <at> linux-m68k.org, 75655 <at> debbugs.gnu.org >> >> --- 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.