bug#53358: 29.0.50; Compilation output messed up again

bug#53358: 29.0.50; Compilation output messed up again

[Lars Ingebrigtsen]

A while back, Paul fixed the compilation output so that we wouldn't get
messed-up "make -j16" output, but recently it's started again:

  ELC      ../lisp/button.elc  ELC      ../lisp/composite.elc
  ELC      ../lisp/buff-menu.elc  ELC      ../lisp/cus-face.elc

  ELC      ../lisp/cus-start.elc
  ELC      ../lisp/custom.elc
  ELC      ../lisp/disp-table.elc  ELC      ../lisp/dnd.elc

  ELC      ../lisp/dos-fns.elc

I think I've seen this the past couple of weeks, possibly?

I don't quite recall what Paul's fixes entailed...  anybody remember?
And does anybody know what has changed in this area lately?


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.16.0)
 of 2022-01-18 built on xo
Repository revision: 5006e19856ea88eb042d1af1cb05136bf2f25cd7
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Debian GNU/Linux bookworm/sid


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53358: 29.0.50; Compilation output messed up again

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> A while back, Paul fixed the compilation output so that we wouldn't get
> messed-up "make -j16" output, but recently it's started again:
>
>   ELC      ../lisp/button.elc  ELC      ../lisp/composite.elc
>   ELC      ../lisp/buff-menu.elc  ELC      ../lisp/cus-face.elc
>
>   ELC      ../lisp/cus-start.elc

Or...  is this perhaps completely unrelated to those fixes?  I forgot
that the ELC lines were output by the Makefiles, not by Emacs.

On the other hand, these messed-up lines only seem to appear if Emacs is
also outputting lines at the same time:

  INFO     Scraping files for mh-loaddefs.el...56% 
  ELC      ../lisp/language/cham.elc
  ELC      ../lisp/language/chinese.elc
  ELC      ../lisp/language/cyrillic.elc
  ELC      ../lisp/language/czech.elc  ELC      ../lisp/language/english.elc

  INFO     Scraping files for mh-loaddefs.el...80% 
  ELC      ../lisp/language/ethiopic.elc
  ELC      ../lisp/language/european.elc
  ELC      ../lisp/language/georgian.elc  ELC      ../lisp/language/greek.elc

  ELC      ../lisp/language/hebrew.elc
  ELC      ../lisp/language/indian.elc
  INFO     Scraping files for mh-loaddefs.el...done

The INFO/Scraping lines are from Emacs at least, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53358: 29.0.50; Compilation output messed up again

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 19 Jan 2022 09:20:36 +0100
> 
> 
> A while back, Paul fixed the compilation output so that we wouldn't get
> messed-up "make -j16" output, but recently it's started again:
> 
>   ELC      ../lisp/button.elc  ELC      ../lisp/composite.elc
>   ELC      ../lisp/buff-menu.elc  ELC      ../lisp/cus-face.elc
> 
>   ELC      ../lisp/cus-start.elc
>   ELC      ../lisp/custom.elc
>   ELC      ../lisp/disp-table.elc  ELC      ../lisp/dnd.elc
> 
>   ELC      ../lisp/dos-fns.elc
> 
> I think I've seen this the past couple of weeks, possibly?
> 
> I don't quite recall what Paul's fixes entailed...  anybody remember?
> And does anybody know what has changed in this area lately?

Maybe the changeset below?

  commit eaa44ca40e8da9ba86e6e03b76b41fd6843661d6
  Author:     Paul Eggert <eggert@cs.ucla.edu>
  AuthorDate: Mon Dec 20 12:14:07 2021 -0800
  Commit:     Paul Eggert <eggert@cs.ucla.edu>
  CommitDate: Mon Dec 20 12:24:04 2021 -0800

      Prefer $(info) to @echo

      Have GNU Make output some diagnostics directly, instead of forking
      and execing a shell to do it.
      * GNUmakefile (help):
      * doc/lispref/two-volume.make (vol2.pdf, elisp2med-init)
      (elisp2-init):
      * doc/misc/Makefile.in (echo-info, echo-sources):
      * lib-src/Makefile.in (archlibdir, install, check):
      * src/verbose.mk.in (AM_V_AR, AM_V_CC, AM_V_CXX, AM_V_CCLD)
      (AM_V_CXXLD, AM_V_ELC, AM_V_ELN, AM_V_GEN, AM_V_GLOBALS)
      (AM_V_RC):
      * test/Makefile.in (subdirs, subdir-targets):
      Prefer $(info) to @echo.
      * GNUmakefile (MAKECMDGOALS, configure, Makefile):
      Prefer $(warning) to @echo >&2.
      * src/verbose.mk.in (AM_V_ELN): Output target, like the others.

bug#53358: 29.0.50; Compilation output messed up again

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe the changeset below?
>
>   commit eaa44ca40e8da9ba86e6e03b76b41fd6843661d6
>   Author:     Paul Eggert <eggert@cs.ucla.edu>
>   AuthorDate: Mon Dec 20 12:14:07 2021 -0800
>   Commit:     Paul Eggert <eggert@cs.ucla.edu>
>   CommitDate: Mon Dec 20 12:24:04 2021 -0800
>
>       Prefer $(info) to @echo

Yup.  To test, I just replaced the info with echo here:

diff --git a/src/verbose.mk.in b/src/verbose.mk.in
index e3f5678303..4f8084433f 100644
--- a/src/verbose.mk.in
+++ b/src/verbose.mk.in
@@ -48,7 +48,7 @@ AM_V_ELC     = @$(info $   ELC+ELN  $@)
 AM_V_ELN     = @$(info $   ELN      $@)
 endif
 else
-AM_V_ELC     = @$(info $   ELC      $@)
+AM_V_ELC = @echo "  ELC     " $@;
 AM_V_ELN =
 endif
 AM_V_GEN     = @$(info $   GEN      $@)

And the problem disappeared.  But echo was presumably changed to info
for a reason, so reverting eaa44ca40e is probably not the right thing.
Paul, is there a way to make $(info) be more atomic?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53358: 29.0.50; Compilation output messed up again

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

On 1/19/22 01:16, Lars Ingebrigtsen wrote:

> echo was presumably changed to info
> for a reason

Yes, it avoids a fork-and-exec and this simplifies strace-style 
debugging of make+sh invocations that go awry.

I am not seeing the problem on my platform (Ubuntu 21.10, Xeon E3-1225 
v2); what platform are you using?

How are you viewing the 'make' output? Are you using M-x compile under 
Emacs, or something else?

Does the problem go away if you use 'make -Oline'?

Does the problem go away if you apply the attached patch to the GNU Make 
source code?

[-- Attachment #2: 0001-Fix-interleaved-info-output.patch --]
[-- Type: text/x-patch, Size: 1600 bytes --]

From d1d2269fbafde7c1b0115dd5c85d82ac4b58677d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 19 Jan 2022 15:20:40 -0800
Subject: [PATCH] Fix interleaved $(info) output
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/function.c (func_error): On POSIX-compatible platforms,
cause $(info xxx) output to a pipe to be atomic when xxx is small,
the same way that $(warning xxx) and $(error xxx) is.  Problem
reported by Lars Ingebrigtsen <https://bugs.gnu.org/r/53358>.
Also, shrink allocation by 1 byte (the byte isn’t ever used)
and avoid an unnecessary initialization of msg[0].
---
 src/function.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/function.c b/src/function.c
index c107a387..05c77c32 100644
--- a/src/function.c
+++ b/src/function.c
@@ -1180,17 +1180,16 @@ func_error (char *o, char **argv, const char *funcname)
   for (len=0, argvp=argv; *argvp != 0; ++argvp)
     len += strlen (*argvp) + 2;
 
-  p = msg = alloca (len + 1);
-  msg[0] = '\0';
+  p = msg = alloca (len);
 
-  for (argvp=argv; argvp[1] != 0; ++argvp)
+  for (argvp=argv; *argvp != 0; ++argvp)
     {
       strcpy (p, *argvp);
       p += strlen (*argvp);
       *(p++) = ',';
       *(p++) = ' ';
     }
-  strcpy (p, *argvp);
+  p[-2] = '\0';
 
   switch (*funcname)
     {
@@ -1202,8 +1201,8 @@ func_error (char *o, char **argv, const char *funcname)
       break;
 
     case 'i':
+      strcpy (p - 2, "\n");
       outputs (0, msg);
-      outputs (0, "\n");
       break;
 
     default:
-- 
2.32.0

bug#53358: 29.0.50; Compilation output messed up again

[Paul Eggert]

On 1/19/22 15:32, Paul Eggert wrote:
> I am not seeing the problem on my platform (Ubuntu 21.10, Xeon E3-1225 
> v2); what platform are you using?

Check that - I got the problem to occur twice (in  by using 'make -j16 
on my 4-core machine) out of 1520 instances of "ELC" when building all 
Emacs .elc files once.

I could not reproduce the problem once the 'make' patch was applied.

Hope it's only a minor irritation for you until 'make' gets fixed....

bug#53358: 29.0.50; Compilation output messed up again

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Check that - I got the problem to occur twice (in  by using 'make -j16
> on my 4-core machine) out of 1520 instances of "ELC" when building all
> Emacs .elc files once.
>
> I could not reproduce the problem once the 'make' patch was applied.

I haven't tried the make patch, but it looks "obviously correct" to me,
so if it went away in your tests, I assume that it's working.

> Hope it's only a minor irritation for you until 'make' gets fixed....

Well...  it's pretty annoying?  The Emacs build is now so
regular-looking that these lines that follow other patterns flag "hm, I
should look at that" when they scroll by.

The problem is just in the ELC bit, so perhaps we can use echo just
there, but keep all the rest of the $(info)s?  (And add a comment saying
that that echo should be rewritten as an $(info) once the fixed make
makes it out into the world.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53358: 29.0.50; Compilation output messed up again

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On 1/20/22 00:10, Lars Ingebrigtsen wrote:
> The problem is just in the ELC bit

Surely it's just an accident that you've seen it only for ELC, as the 
problem can occur if 'make' executes any two $(info ...)s at about the 
same time.

How badly does it occur for you? For me, it's only the first line (when 
many 'makes' start in parallel, which is a glitch I can easily ignore.

If it's a real annoyance please try the attached patch, which should fix 
the problem for the AM_V_ stuff at the cost of appending annoying empty 
lines with current and older GNU make. (Which annoyance do you prefer? 
:-) You'll need to run './config.status' after applying the patch.

[-- Attachment #2: 0001-Work-around-GNU-Make-info-bug.patch --]
[-- Type: text/x-patch, Size: 3118 bytes --]

From 153f3d9af2b3d021d9ba8eb17d979c772a7c09cd Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 20 Jan 2022 10:11:39 -0800
Subject: [PATCH] Work around GNU Make $(info) bug

Problem reported by Lars Ingebrigtsen (Bug#53358).
* src/verbose.mk.in (newline, info-trailing-newline): New macros.
(AM_V_AR, AM_V_CC, AM_V_CXX, AM_V_CCLD, AM_V_CXXLD, AM_V_ELC)
(AM_V_ELN, AM_V_GEN, AM_V_RC): Use them.
---
 src/verbose.mk.in | 42 +++++++++++++++++++++++++++++++-----------
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/src/verbose.mk.in b/src/verbose.mk.in
index e3f5678303..4a3bbcb9de 100644
--- a/src/verbose.mk.in
+++ b/src/verbose.mk.in
@@ -17,6 +17,26 @@
 ## You should have received a copy of the GNU General Public License
 ## along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
 
+# Use two empty lines to define a macro containing a newline.
+define newline
+
+
+endef
+
+# Work around a bug in GNU Make 4.3 and earlier, which implements $(info MSG)
+# via two system calls { write (..., "MSG", 3); write (..., "\n", 1); }
+# which looks bad when make -j interleaves two of these at about the same time.
+# Later versions of GNU Make have the 'notintermediate' feature,
+# so assume that $(info ...) has the bug if this feature is absent.
+# The workaround arranges for 'MSG' itself to end in newline;
+# although this follows every message by an empty line,
+# that's better than the interleaved output.
+ifeq (,$(filter notintermediate,$(value .FEATURES)))
+info-trailing-newline = $(newline)
+else
+info-trailing-newline =
+endif
+
 # 'make' verbosity.
 V = @AM_DEFAULT_VERBOSITY@
 ifeq (${V},1)
@@ -33,26 +53,26 @@ AM_V_GLOBALS =
 AM_V_NO_PD =
 AM_V_RC =
 else
-AM_V_AR      = @$(info $   AR       $@)
+AM_V_AR      = @$(info $   AR       $@$(info-trailing-newline))
 AM_V_at = @
-AM_V_CC      = @$(info $   CC       $@)
-AM_V_CXX     = @$(info $   CXX      $@)
-AM_V_CCLD    = @$(info $   CCLD     $@)
-AM_V_CXXLD   = @$(info $   CXXLD    $@)
+AM_V_CC      = @$(info $   CC       $@$(info-trailing-newline))
+AM_V_CXX     = @$(info $   CXX      $@$(info-trailing-newline))
+AM_V_CCLD    = @$(info $   CCLD     $@$(info-trailing-newline))
+AM_V_CXXLD   = @$(info $   CXXLD    $@$(info-trailing-newline))
 ifeq ($(HAVE_NATIVE_COMP),yes)
 ifeq ($(NATIVE_DISABLED),1)
-AM_V_ELC     = @$(info $   ELC      $@)
+AM_V_ELC     = @$(info $   ELC      $@$(info-trailing-newline))
 AM_V_ELN =
 else
-AM_V_ELC     = @$(info $   ELC+ELN  $@)
-AM_V_ELN     = @$(info $   ELN      $@)
+AM_V_ELC     = @$(info $   ELC+ELN  $@$(info-trailing-newline))
+AM_V_ELN     = @$(info $   ELN      $@$(info-trailing-newline))
 endif
 else
-AM_V_ELC     = @$(info $   ELC      $@)
+AM_V_ELC     = @$(info $   ELC      $@$(info-trailing-newline))
 AM_V_ELN =
 endif
-AM_V_GEN     = @$(info $   GEN      $@)
+AM_V_GEN     = @$(info $   GEN      $@$(info-trailing-newline))
 AM_V_GLOBALS = @$(info $   GEN      globals.h)
 AM_V_NO_PD = --no-print-directory
-AM_V_RC      = @$(info $   RC       $@)
+AM_V_RC      = @$(info $   RC       $@$(info-trailing-newline))
 endif
-- 
2.32.0

bug#53358: 29.0.50; Compilation output messed up again

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Surely it's just an accident that you've seen it only for ELC, as the
> problem can occur if 'make' executes any two $(info ...)s at about the
> same time.

In principle, but that's the only place I'm seeing this.

> How badly does it occur for you? For me, it's only the first line
> (when many 'makes' start in parallel, which is a glitch I can easily
> ignore.

I see it on every build I do (8 core machine, 16 threads, so I use
-j16).  And since the build is so nice and warning-free these days,
those messed-up lines stick out.

> If it's a real annoyance please try the attached patch, which should
> fix the problem for the AM_V_ stuff at the cost of appending annoying
> empty lines with current and older GNU make. (Which annoyance do you
> prefer? :-) You'll need to run './config.status' after applying the
> patch.

Unfortunately there's been other changes in these files, so the patch no
longer applies.  But I don't think it makes sense to work around this
problem by making the output look worse for most people, so I'd rather
just avoid using $(info) in the problematic parts -- then it'll look OK
for everybody (and without obfuscation).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53358: 29.0.50; Compilation output messed up again

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On 1/21/22 01:24, Lars Ingebrigtsen wrote:
> I see it on every build I do (8 core machine, 16 threads, so I use
> -j16).

Ah, your machine is beefier than mine.

I installed the attached to attempt to implement your suggestion to use 
an 'echo' workaround only for "ELC"-like lines. Please give it a try.

The workaround is used only for current (and older) versions of GNU 
Make, so it will phase itself out eventually. In the meantime I can use 
bleeding-edge Make to debug without worrying about the extra processes 
generated by the 'echo' approach.

[-- Attachment #2: 0001-Simplify-AM_V_ELC-setup.patch --]
[-- Type: text/x-patch, Size: 1329 bytes --]

From 882bbeb1f9f40ccf9f1e3f3423fd7cb12a4859ab Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 21 Jan 2022 13:33:55 -0800
Subject: [PATCH 1/2] Simplify AM_V_ELC setup
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/verbose.mk.in (AM_V_ELC, AM_V_ELN): Use simpler Make ‘if’s.
---
 src/verbose.mk.in | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/src/verbose.mk.in b/src/verbose.mk.in
index 01076df946..c0bf67abd4 100644
--- a/src/verbose.mk.in
+++ b/src/verbose.mk.in
@@ -39,23 +39,13 @@ AM_V_CC      = @$(info $   CC       $@)
 AM_V_CXX     = @$(info $   CXX      $@)
 AM_V_CCLD    = @$(info $   CCLD     $@)
 AM_V_CXXLD   = @$(info $   CXXLD    $@)
-ifeq ($(HAVE_NATIVE_COMP),yes)
-ifneq ($(NATIVE_DISABLED),1)
-ifneq ($(ANCIENT),yes)
+ifeq ($(HAVE_NATIVE_COMP)-$(NATIVE_DISABLED)-$(ANCIENT),yes--)
 AM_V_ELC     = @$(info $   ELC+ELN  $@)
 AM_V_ELN     = @$(info $   ELN      $@)
 else
 AM_V_ELC     = @$(info $   ELC      $@)
 AM_V_ELN =
 endif
-else
-AM_V_ELC     = @$(info $   ELC      $@)
-AM_V_ELN =
-endif
-else
-AM_V_ELC     = @$(info $   ELC      $@)
-AM_V_ELN =
-endif
 AM_V_GEN     = @$(info $   GEN      $@)
 AM_V_GLOBALS = @$(info $   GEN      globals.h)
 AM_V_NO_PD = --no-print-directory
-- 
2.32.0


[-- Attachment #3: 0002-Avoid-glitches-in-ELC-lines-in-build-output.patch --]
[-- Type: text/x-patch, Size: 2068 bytes --]

From fac8d0ac2f4cbdbd5828a57ddc90adf6601d956b Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 21 Jan 2022 14:45:57 -0800
Subject: [PATCH 2/2] Avoid glitches in ELC lines in build output

* src/verbose.mk.in (have_working_info): New macro.
(AM_V_ELC, AM_V_ELN): Use 'echo' rather than $(info ...)
on buggy versions of GNU Make.
---
 src/verbose.mk.in | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/src/verbose.mk.in b/src/verbose.mk.in
index c0bf67abd4..eb99e42695 100644
--- a/src/verbose.mk.in
+++ b/src/verbose.mk.in
@@ -33,19 +33,45 @@ AM_V_GLOBALS =
 AM_V_NO_PD =
 AM_V_RC =
 else
+
+# Whether $(info ...) works.  This is to work around a bug in GNU Make
+# 4.3 and earlier, which implements $(info MSG) via two system calls
+# { write (..., "MSG", 3); write (..., "\n", 1); }
+# which looks bad when make -j interleaves two of these at about the same time.
+#
+# Later versions of GNU Make have the 'notintermediate' feature,
+# so assume that $(info ...) works if this feature is present.
+#
+have_working_info = $(filter notintermediate,$(value .FEATURES))
+#
+# The workaround is to use the shell and 'echo' rather than $(info ...).
+# The workaround is done only for AM_V_ELC and AM_V_ELN,
+# since the bug is not annoying elsewhere.
+
 AM_V_AR      = @$(info $   AR       $@)
 AM_V_at = @
 AM_V_CC      = @$(info $   CC       $@)
 AM_V_CXX     = @$(info $   CXX      $@)
 AM_V_CCLD    = @$(info $   CCLD     $@)
 AM_V_CXXLD   = @$(info $   CXXLD    $@)
+
 ifeq ($(HAVE_NATIVE_COMP)-$(NATIVE_DISABLED)-$(ANCIENT),yes--)
+ifdef have_working_info
 AM_V_ELC     = @$(info $   ELC+ELN  $@)
 AM_V_ELN     = @$(info $   ELN      $@)
 else
+AM_V_ELC     = @echo "  ELC+ELN " $@;
+AM_V_ELN     = @echo "  ELN     " $@;
+endif
+else
+ifdef have_working_info
 AM_V_ELC     = @$(info $   ELC      $@)
+else
+AM_V_ELC     = @echo "  ELC     " $@;
+endif
 AM_V_ELN =
 endif
+
 AM_V_GEN     = @$(info $   GEN      $@)
 AM_V_GLOBALS = @$(info $   GEN      globals.h)
 AM_V_NO_PD = --no-print-directory
-- 
2.32.0

bug#53358: 29.0.50; Compilation output messed up again

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> I installed the attached to attempt to implement your suggestion to
> use an 'echo' workaround only for "ELC"-like lines. Please give it a
> try.

Thanks; but it doesn't seem to have had any effect here
(Debian/bookworm).  I still get:

  GEN      mh-e/mh-loaddefs.el
  ELC      ../lisp/files.elc
  ELC      ../lisp/font-lock.elc  ELC      ../lisp/font-core.elc

  GEN      net/tramp-loaddefs.el
  ELC      ../lisp/format.elc
  ELC      ../lisp/frame.elc
  ELC      ../lisp/fringe.elc  ELC      ../lisp/help.elc

  ELC      ../lisp/indent.elc
  ELC      ../lisp/image.elc
  ELC      ../lisp/international/charscript.elc
  ELC      ../lisp/international/emoji-zwj.elc

This is with a "make -j16 bootstrap" after doing a "make" after "git
clean -xf", to ensure that all the files are rebuilt.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53358: 29.0.50; Compilation output messed up again

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

On 1/22/22 02:16, Lars Ingebrigtsen wrote:
> This is with a "make -j16 bootstrap" after doing a "make" after "git
> clean -xf", to ensure that all the files are rebuilt.

Oh, I messed up and used ifdef when I should have used ifneq. I 
installed the attached to fix that.

[-- Attachment #2: 0001-Avoid-glitches-in-ELC-lines-in-build-output.patch --]
[-- Type: text/x-patch, Size: 1212 bytes --]

From eeb84de340e6f1fd53c56336b3a02e502212cf78 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 23 Jan 2022 23:22:04 -0800
Subject: [PATCH] Avoid glitches in ELC lines in build output
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/verbose.mk.in (AM_V_ELC, AM_V_ELN): Use ifneq not ifdef, as
we want have_working_info’s value expanded (Bug#53358).
---
 src/verbose.mk.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/verbose.mk.in b/src/verbose.mk.in
index eb99e42695..4ec7788442 100644
--- a/src/verbose.mk.in
+++ b/src/verbose.mk.in
@@ -56,7 +56,7 @@ AM_V_CCLD    = @$(info $   CCLD     $@)
 AM_V_CXXLD   = @$(info $   CXXLD    $@)
 
 ifeq ($(HAVE_NATIVE_COMP)-$(NATIVE_DISABLED)-$(ANCIENT),yes--)
-ifdef have_working_info
+ifneq (,$(have_working_info))
 AM_V_ELC     = @$(info $   ELC+ELN  $@)
 AM_V_ELN     = @$(info $   ELN      $@)
 else
@@ -64,7 +64,7 @@ AM_V_ELC     = @echo "  ELC+ELN " $@;
 AM_V_ELN     = @echo "  ELN     " $@;
 endif
 else
-ifdef have_working_info
+ifneq (,$(have_working_info))
 AM_V_ELC     = @$(info $   ELC      $@)
 else
 AM_V_ELC     = @echo "  ELC     " $@;
-- 
2.32.0

bug#53358: 29.0.50; Compilation output messed up again

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Oh, I messed up and used ifdef when I should have used ifneq. I
> installed the attached to fix that.

Thanks; that seems to fix the issue here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no