GNU bug report logs - #53358
29.0.50; Compilation output messed up again

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53358 in the body.
You can then email your comments to 53358 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Compilation output messed up again
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?


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

Message #8 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Wed, 19 Jan 2022 09:36:17 +0100

Lars Ingebrigtsen <larsi <at> 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

Message #11 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Wed, 19 Jan 2022 11:07:43 +0200

> From: Lars Ingebrigtsen <larsi <at> 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 <at> cs.ucla.edu>
  AuthorDate: Mon Dec 20 12:14:07 2021 -0800
  Commit:     Paul Eggert <eggert <at> 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.

Message #14 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Wed, 19 Jan 2022 10:16:03 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Maybe the changeset below?
>
>   commit eaa44ca40e8da9ba86e6e03b76b41fd6843661d6
>   Author:     Paul Eggert <eggert <at> cs.ucla.edu>
>   AuthorDate: Mon Dec 20 12:14:07 2021 -0800
>   Commit:     Paul Eggert <eggert <at> 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

Message #17 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Wed, 19 Jan 2022 15:32:50 -0800

[Message part 1 (text/plain, inline)]

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?

[0001-Fix-interleaved-info-output.patch (text/x-patch, attachment)]

Message #20 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Wed, 19 Jan 2022 15:53:00 -0800

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....

Message #23 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Thu, 20 Jan 2022 09:10:56 +0100

Paul Eggert <eggert <at> 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

Message #26 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Thu, 20 Jan 2022 10:21:17 -0800

[Message part 1 (text/plain, inline)]

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.

[0001-Work-around-GNU-Make-info-bug.patch (text/x-patch, attachment)]

Message #29 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Fri, 21 Jan 2022 10:24:58 +0100

Paul Eggert <eggert <at> 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

Message #34 received at 53358-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 53358-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Fri, 21 Jan 2022 14:52:50 -0800

[Message part 1 (text/plain, inline)]

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.

[0001-Simplify-AM_V_ELC-setup.patch (text/x-patch, attachment)]

[0002-Avoid-glitches-in-ELC-lines-in-build-output.patch (text/x-patch, attachment)]

Message #37 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Sat, 22 Jan 2022 11:16:26 +0100

Paul Eggert <eggert <at> 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

Message #40 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Sun, 23 Jan 2022 23:25:13 -0800

[Message part 1 (text/plain, inline)]

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.

[0001-Avoid-glitches-in-ELC-lines-in-build-output.patch (text/x-patch, attachment)]

Message #43 received at 53358 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 53358 <at> debbugs.gnu.org
Subject: Re: bug#53358: 29.0.50; Compilation output messed up again
Date: Mon, 24 Jan 2022 10:47:19 +0100

Paul Eggert <eggert <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.