[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `message' not outputting the newline "atomically"

From: Paul Eggert
Subject: Re: `message' not outputting the newline "atomically"
Date: Mon, 8 Jul 2019 19:47:26 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

Eli Zaretskii wrote:

I proposed -O.  Then Lars said that use of 'message'
is not limited to building Emacs, and we embarked on the rest of the

OK, I see the background better now. However, it's not just 'message', as Emacs will output to stderr in a few other places when I run it in the background from my terminal window (or whatever), even when Emacs is is not generating debugging output or a fatal error message. These other places should also be fixed.

As for "make -O", could it be that you were talking literally about
that, i.e. about "make -O=target"?  Because I meant "make -O=line",
which AFAIR slows down the build only slightly, and provides the
line-level separation that you want to see

Give the background you mentioned, 'make -O' is a cold trail since it doesn't suffice to fix the other problems. That being said, 'make -Oline' does have delays that slow me down. For example, when 'make -Oline' compiles src/xdisp.c, it doesn't show me any of GCC's output until GCC exits. On my desktop in some cases that's a 15-second wait for a diagnostic that I can see in a few milliseconds if I don't use -O.

I don't want us to buffer diagnostics and fatal error messages.  The
other messages, such as the one which outputs the pdumper fingerprint,
could be modified to not mix with others

With that constraint in mind, I thought of a fix that's simpler and and more straightforward than what I sent you earlier. The idea is to output the other messages to stdout, not stderr. That way, they'll avoid the interleaving problem, and it'll be easier to separate them from debugging diagnostics and fatal error messages. Proposed patch attached; it attempts to identify all the places that output these "other messages".

Attachment: 0001-Send-informative-messages-to-stdout-not-stderr.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]