all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* src/Makefile unhelpful
@ 2022-09-07  2:19 Richard Stallman
  2022-09-07  2:38 ` Po Lu
                   ` (2 more replies)
  0 siblings, 3 replies; 52+ messages in thread
From: Richard Stallman @ 2022-09-07  2:19 UTC (permalink / raw)
  To: eliz, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Building temacs, when compiling the C source files, outputs lines like these

  CC       dispnew.o
  CC       frame.o
  CC       scroll.o
  CC       xdisp.o

which don't show the arguments actually used.
(Why does it show that instead of the actual command?
What code in the Makefile causes this?
Perhaps add comments to explain this.)

To show all the arguments on each line would be a nuisance,
but when one wants to investigate what they were,
I find no easy way to do it.  How do you do that?

Anyway, I think it would be useful for each make run to output, for
debugging, each actual command.  It could show each of the usual
commands once, or (if it isn't hard) only the usual commands that were
actually executed.  To show, for instance, what this expands into:

	$(AM_V_CC)$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $(PROFILING_CFLAGS)

at least if the .c.o rule is ever used.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-07  2:19 src/Makefile unhelpful Richard Stallman
@ 2022-09-07  2:38 ` Po Lu
  2022-09-07  2:41 ` Eli Zaretskii
  2022-09-07  3:11 ` Sam James
  2 siblings, 0 replies; 52+ messages in thread
From: Po Lu @ 2022-09-07  2:38 UTC (permalink / raw)
  To: Richard Stallman; +Cc: eliz, emacs-devel

Richard Stallman <rms@gnu.org> writes:

> To show all the arguments on each line would be a nuisance,
> but when one wants to investigate what they were,
> I find no easy way to do it.  How do you do that?

I think you have to make V=1.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-07  2:19 src/Makefile unhelpful Richard Stallman
  2022-09-07  2:38 ` Po Lu
@ 2022-09-07  2:41 ` Eli Zaretskii
  2022-09-08  3:00   ` Richard Stallman
  2022-09-07  3:11 ` Sam James
  2 siblings, 1 reply; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-07  2:41 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 06 Sep 2022 22:19:08 -0400
> 
> Building temacs, when compiling the C source files, outputs lines like these
> 
>   CC       dispnew.o
>   CC       frame.o
>   CC       scroll.o
>   CC       xdisp.o
> 
> which don't show the arguments actually used.
> (Why does it show that instead of the actual command?
> What code in the Makefile causes this?
> Perhaps add comments to explain this.)
> 
> To show all the arguments on each line would be a nuisance,
> but when one wants to investigate what they were,
> I find no easy way to do it.  How do you do that?

The way to see the arguments is to say

  make V=1

> Anyway, I think it would be useful for each make run to output, for
> debugging, each actual command.  It could show each of the usual
> commands once, or (if it isn't hard) only the usual commands that were
> actually executed.  To show, for instance, what this expands into:
> 
> 	$(AM_V_CC)$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $(PROFILING_CFLAGS)
> 
> at least if the .c.o rule is ever used.

I think this is rarely needed, so having it silent by default is
better.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-07  2:19 src/Makefile unhelpful Richard Stallman
  2022-09-07  2:38 ` Po Lu
  2022-09-07  2:41 ` Eli Zaretskii
@ 2022-09-07  3:11 ` Sam James
  2 siblings, 0 replies; 52+ messages in thread
From: Sam James @ 2022-09-07  3:11 UTC (permalink / raw)
  To: rms; +Cc: eliz, emacs-devel

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



> On 7 Sep 2022, at 03:19, Richard Stallman <rms@gnu.org> wrote:
> 
> [snip]
> To show all the arguments on each line would be a nuisance,
> but when one wants to investigate what they were,
> I find no easy way to do it.  How do you do that?

Another option to make V=1 (you can do something like: export MAKEOPTS="V=1 -j$(nproc)"
may be ./configure --disable-silent-rules.

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-07  2:41 ` Eli Zaretskii
@ 2022-09-08  3:00   ` Richard Stallman
  2022-09-08  4:51     ` Sam James
  2022-09-08  6:14     ` Eli Zaretskii
  0 siblings, 2 replies; 52+ messages in thread
From: Richard Stallman @ 2022-09-08  3:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Anyway, I think it would be useful for each make run to output, for
  > > debugging, each actual command.  It could show each of the usual
  > > commands once, or (if it isn't hard) only the usual commands that were
  > > actually executed.  To show, for instance, what this expands into:
  > > 
  > > 
  > > at least if the .c.o rule is ever used.

  > I think this is rarely needed, so having it silent by default is
  > better.

We may be miscommunicating.  My idea is that each make run that runs
the command

 	$(AM_V_CC)$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $(PROFILING_CFLAGS)

at least once, should output _just once_ what that expands into.

I agree we do not want to output the expansion more than once.

  > The way to see the arguments is to say

  >   make V=1

The problem with that solution is that by October I certainly won't
remember it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-08  3:00   ` Richard Stallman
@ 2022-09-08  4:51     ` Sam James
  2022-09-11  3:38       ` Richard Stallman
  2022-09-08  6:14     ` Eli Zaretskii
  1 sibling, 1 reply; 52+ messages in thread
From: Sam James @ 2022-09-08  4:51 UTC (permalink / raw)
  To: rms; +Cc: Eli Zaretskii, emacs-devel

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



> On 8 Sep 2022, at 04:00, Richard Stallman <rms@gnu.org> wrote:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>>> Anyway, I think it would be useful for each make run to output, for
>>> debugging, each actual command.  It could show each of the usual
>>> commands once, or (if it isn't hard) only the usual commands that were
>>> actually executed.  To show, for instance, what this expands into:
>>> 
>>> 
>>> at least if the .c.o rule is ever used.
> 
>> I think this is rarely needed, so having it silent by default is
>> better.
> 
> We may be miscommunicating.  My idea is that each make run that runs
> the command
> 
> 	$(AM_V_CC)$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $(PROFILING_CFLAGS)
> 
> at least once, should output _just once_ what that expands into.
> 
> I agree we do not want to output the expansion more than once.

Note that CFLAGS can (I don't speak for whether they do in Emacs)
vary per file, target, directory, ...

As for CC, I think you could read configure output if you're particularly
interested in that.

I think if you do want this, the best place to recommend it would be
the automake mailing lists. Emacs will become harder to maintain
if it develops quirks like this, and it'll be confusing to outsiders
who are familiar with automake to see such an odd construct.

> 
>> The way to see the arguments is to say
> 
>>  make V=1
> 
> The problem with that solution is that by October I certainly won't
> remember it.

You could put it in an alias or MAKEOPTS or something,
although it may not work with some homebrew Makefiles
(projects other than Emacs, not using autotools).

Best,
sam


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-08  3:00   ` Richard Stallman
  2022-09-08  4:51     ` Sam James
@ 2022-09-08  6:14     ` Eli Zaretskii
  2022-09-08  7:29       ` Andreas Schwab
                         ` (2 more replies)
  1 sibling, 3 replies; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-08  6:14 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 07 Sep 2022 23:00:44 -0400
> 
>   > I think this is rarely needed, so having it silent by default is
>   > better.
> 
> We may be miscommunicating.  My idea is that each make run that runs
> the command
> 
>  	$(AM_V_CC)$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $(PROFILING_CFLAGS)
> 
> at least once, should output _just once_ what that expands into.
> 
> I agree we do not want to output the expansion more than once.

I understood, but I think it isn't needed even once, because we don't
care about the exact command unless we run into some trouble.

The command is quite long, so outputting it even once will write a lot
of stuff to the screen, stuff that we almost always ignore.

>   > The way to see the arguments is to say
> 
>   >   make V=1
> 
> The problem with that solution is that by October I certainly won't
> remember it.

It's a general Autoconf-based solution many/all GNU projects use, so
if we want to change that to something more memorable, we should
change that across the board.

(FWIW, I keep notes in a prominent place about important stuff I'm
likely to forget due to rare use.)



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-08  6:14     ` Eli Zaretskii
@ 2022-09-08  7:29       ` Andreas Schwab
  2022-09-08 13:18       ` Stefan Monnier
  2022-09-11  3:38       ` Richard Stallman
  2 siblings, 0 replies; 52+ messages in thread
From: Andreas Schwab @ 2022-09-08  7:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rms, emacs-devel

On Sep 08 2022, Eli Zaretskii wrote:

> It's a general Autoconf-based solution many/all GNU projects use, so

It originates from automake (AM_SILENT_RULES).

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-08  6:14     ` Eli Zaretskii
  2022-09-08  7:29       ` Andreas Schwab
@ 2022-09-08 13:18       ` Stefan Monnier
  2022-09-11  3:38       ` Richard Stallman
  2 siblings, 0 replies; 52+ messages in thread
From: Stefan Monnier @ 2022-09-08 13:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rms, emacs-devel

> It's a general Autoconf-based solution many/all GNU projects use, so
> if we want to change that to something more memorable, we should
> change that across the board.

Agreed.  FWIW, I have found it difficult to find the right incantation,
so maybe we should document it in the `Commentary:` section of the
Makefile(.in)?


        Stefan




^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-08  4:51     ` Sam James
@ 2022-09-11  3:38       ` Richard Stallman
  2022-09-11  5:34         ` Eli Zaretskii
  0 siblings, 1 reply; 52+ messages in thread
From: Richard Stallman @ 2022-09-11  3:38 UTC (permalink / raw)
  To: Sam James; +Cc: eliz, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I agree we do not want to output the expansion more than once.

  > Note that CFLAGS can (I don't speak for whether they do in Emacs)
  > vary per file, target, directory, ...

I'm asking for this in Emacs, and obly Emacs.

The other programs I've worked on did not need anything like this.
Their makefile commands were simple enough that you could figure
out the precise options easily enough.

So instead of proposing new features for make or automake,
which nobody here is likely to work on, let's look for
a simple way to implement this in the makefiles for Emacs itself.

  > As for CC, I think you could read configure output if you're particularly
  > interested in that.

I'd have to figure out which make variables get used, since the output
does not say.  Then find out the value of each of them.  It would be
a lot of work.

With the feature I proposed, it would be pretty easy.

  > I think if you do want this, the best place to recommend it would be
  > the automake mailing lists. Emacs will become harder to maintain
  > if it develops quirks like this,

Alas, the quirks are already implemented.  This command-explaining feature
would not require any of the complexity.

  > >> The way to see the arguments is to say
  > > 
  > >>  make V=1

How about adding a make command such as

      @echo Use V=1 to see the actual compilation commands

to run near the start of the make run.  That would inform people.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-08  6:14     ` Eli Zaretskii
  2022-09-08  7:29       ` Andreas Schwab
  2022-09-08 13:18       ` Stefan Monnier
@ 2022-09-11  3:38       ` Richard Stallman
  2022-09-11  5:42         ` Eli Zaretskii
  2 siblings, 1 reply; 52+ messages in thread
From: Richard Stallman @ 2022-09-11  3:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I understood, but I think it isn't needed even once, because we don't
  > care about the exact command unless we run into some trouble.

I agree.  I brought this up because I did run into some kind of trouble,
and I could not find a way to see what the commands actually were.

I proposed a solution with the advantage that you don't need to remember
how to invoke it.

  > The command is quite long, so outputting it even once will write a lot
  > of stuff to the screen, stuff that we almost always ignore.

That is normal for output from make.  Most of the output from make, we
normally ignore.  Each line of output is useful when it is pertinent
to some problem.  With hundreds of lines of that, there is no harm
adding a few lines more.

  > It's a general Autoconf-based solution many/all GNU projects use, so
  > if we want to change that to something more memorable, we should
  > change that across the board.

In reaching that conclusion you have implicitly rejected other kinds
of solutions.  Unfortunately, this one has a fatal flaw: the autotools
don't have a lot of people working on them.  If there were a good
solution in Autoconf or Automake, it would probably not get
implemented.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11  3:38       ` Richard Stallman
@ 2022-09-11  5:34         ` Eli Zaretskii
  2022-09-11  9:57           ` Lars Ingebrigtsen
  2022-09-11 15:16           ` Werner LEMBERG
  0 siblings, 2 replies; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-11  5:34 UTC (permalink / raw)
  To: rms; +Cc: sam, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Sat, 10 Sep 2022 23:38:09 -0400
> 
> How about adding a make command such as
> 
>       @echo Use V=1 to see the actual compilation commands
> 
> to run near the start of the make run.  That would inform people.

That's possible.  Let me think about it.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11  3:38       ` Richard Stallman
@ 2022-09-11  5:42         ` Eli Zaretskii
  2022-09-14  4:12           ` Richard Stallman
  0 siblings, 1 reply; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-11  5:42 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 10 Sep 2022 23:38:14 -0400
> 
>   > The command is quite long, so outputting it even once will write a lot
>   > of stuff to the screen, stuff that we almost always ignore.
> 
> That is normal for output from make.  Most of the output from make, we
> normally ignore.

Not anymore.  Many/most GNU projects migrated to the short form you
see in Emacs years ago, and as result the build process of many
projects is much less chatty nowadays.

These short forms use Make macros defined by Automake, so it isn't
something specific to Emacs.  The only Emacs-specific aspects are the
commands that aren't seen in other builds, like byte-compilation --
for those we invented our own short names.  But C/C++ compilation,
linking, production of auto-generated files, etc. -- all this is used
by many other GNU projects.

>   > It's a general Autoconf-based solution many/all GNU projects use, so
>   > if we want to change that to something more memorable, we should
>   > change that across the board.
> 
> In reaching that conclusion you have implicitly rejected other kinds
> of solutions.  Unfortunately, this one has a fatal flaw: the autotools
> don't have a lot of people working on them.  If there were a good
> solution in Autoconf or Automake, it would probably not get
> implemented.

Nevertheless, the problem you raise is common to all GNU projects
using autotools.  So, regardless of whether we implement our own
solution for that, I think you should raise that on the autotools
forum.  IMO, problems should be raised even if we don't believe they
will be worked on, just so people knew and acknowledged that they
exist, and that problems they themselves experience are not their
private ones.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11  5:34         ` Eli Zaretskii
@ 2022-09-11  9:57           ` Lars Ingebrigtsen
  2022-09-11 11:59             ` Po Lu
  2022-09-11 15:16           ` Werner LEMBERG
  1 sibling, 1 reply; 52+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-11  9:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rms, sam, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> How about adding a make command such as
>> 
>>       @echo Use V=1 to see the actual compilation commands
>> 
>> to run near the start of the make run.  That would inform people.
>
> That's possible.  Let me think about it.

I think just putting that in a comment at the top of the Makefile should
be sufficient.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11  9:57           ` Lars Ingebrigtsen
@ 2022-09-11 11:59             ` Po Lu
  2022-09-11 12:07               ` Eli Zaretskii
  2022-09-13  4:07               ` Richard Stallman
  0 siblings, 2 replies; 52+ messages in thread
From: Po Lu @ 2022-09-11 11:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, rms, sam, emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think just putting that in a comment at the top of the Makefile should
> be sufficient.

Or maybe in etc/DEBUG, which is where instructions for debugging Emacs
and its build process are placed.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11 11:59             ` Po Lu
@ 2022-09-11 12:07               ` Eli Zaretskii
  2022-09-11 12:16                 ` Lars Ingebrigtsen
  2022-09-13  4:07               ` Richard Stallman
  1 sibling, 1 reply; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-11 12:07 UTC (permalink / raw)
  To: Po Lu; +Cc: larsi, rms, sam, emacs-devel

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rms@gnu.org,  sam@gentoo.org,
>   emacs-devel@gnu.org
> Date: Sun, 11 Sep 2022 19:59:34 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > I think just putting that in a comment at the top of the Makefile should
> > be sufficient.
> 
> Or maybe in etc/DEBUG, which is where instructions for debugging Emacs
> and its build process are placed.

Maybe _also_ there.  But if it's _only_ there, I doubt that people who
don't know about V=1 will think of looking there.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11 12:07               ` Eli Zaretskii
@ 2022-09-11 12:16                 ` Lars Ingebrigtsen
  0 siblings, 0 replies; 52+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-11 12:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, rms, sam, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe _also_ there.  But if it's _only_ there, I doubt that people who
> don't know about V=1 will think of looking there.

If somebody is curious about how something is built, they'll look at the
Makefile and they'll look at the README.

Which is why we have lengthy commentary and instructions in the
Makefile.  We just don't mention V=1 currently there.




^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11  5:34         ` Eli Zaretskii
  2022-09-11  9:57           ` Lars Ingebrigtsen
@ 2022-09-11 15:16           ` Werner LEMBERG
  2022-09-12  4:35             ` Richard Stallman
  1 sibling, 1 reply; 52+ messages in thread
From: Werner LEMBERG @ 2022-09-11 15:16 UTC (permalink / raw)
  To: eliz; +Cc: rms, sam, emacs-devel


>> How about adding a make command such as
>> 
>>       @echo Use V=1 to see the actual compilation commands
>> 
>> to run near the start of the make run.  That would inform people.
> 
> That's possible.  Let me think about it.

Another possibility would be to implement `make help` to show the
possible targets and variables to control them.


    Werner



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11 15:16           ` Werner LEMBERG
@ 2022-09-12  4:35             ` Richard Stallman
  0 siblings, 0 replies; 52+ messages in thread
From: Richard Stallman @ 2022-09-12  4:35 UTC (permalink / raw)
  To: Werner LEMBERG; +Cc: eliz, sam, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Another possibility would be to implement `make help` to show the
  > possible targets and variables to control them.

That would be good if people expected to use that command.
Currently they don't.

We could make it part of the GNU coding standards -- then people
might try it when they seek such information.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11 11:59             ` Po Lu
  2022-09-11 12:07               ` Eli Zaretskii
@ 2022-09-13  4:07               ` Richard Stallman
  2022-09-13 16:11                 ` Eli Zaretskii
  1 sibling, 1 reply; 52+ messages in thread
From: Richard Stallman @ 2022-09-13  4:07 UTC (permalink / raw)
  To: Po Lu; +Cc: larsi, eliz, sam, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If there is a way to output a message about how to request this
feature in the make output, after the first use of a command that
hides its actual text, or the first use of each command that
hides its actual text, that will assure people see it this feature.

etc/DEBUG and a comment at the top are good places to use also.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-13  4:07               ` Richard Stallman
@ 2022-09-13 16:11                 ` Eli Zaretskii
  2022-09-14 20:02                   ` Alfred M. Szmidt
  0 siblings, 1 reply; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-13 16:11 UTC (permalink / raw)
  To: rms; +Cc: luangruo, larsi, sam, emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, eliz@gnu.org, sam@gentoo.org, emacs-devel@gnu.org
> Date: Tue, 13 Sep 2022 00:07:13 -0400
> 
> If there is a way to output a message about how to request this
> feature in the make output, after the first use of a command that
> hides its actual text, or the first use of each command that
> hides its actual text, that will assure people see it this feature.
> 
> etc/DEBUG and a comment at the top are good places to use also.

Would the below be good enough?

I looked at etc/DEBUG, but it doesn't discuss build-time problems,
only how to debug Emacs that was already built.  So there doesn't seem
to be a good place there to mention this.

diff --git a/Makefile.in b/Makefile.in
index d288bac..119a96e 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -20,6 +20,8 @@
 ### Commentary:
 
 # make all	to compile and build Emacs.
+# make all V=1	to compile and build Emacs with "Verbose" output -- this
+#		causes Make to show the full commands it is invoking.
 # make install	to install it.
 # make TAGS	to update tags tables.
 #



^ permalink raw reply related	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-11  5:42         ` Eli Zaretskii
@ 2022-09-14  4:12           ` Richard Stallman
  2022-09-14 11:33             ` Eli Zaretskii
  0 siblings, 1 reply; 52+ messages in thread
From: Richard Stallman @ 2022-09-14  4:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > These short forms use Make macros defined by Automake, so it isn't
  > something specific to Emacs.  The only Emacs-specific aspects are the
  > commands that aren't seen in other builds, like byte-compilation --
  > for those we invented our own short names.  But C/C++ compilation,
  > linking, production of auto-generated files, etc. -- all this is used
  > by many other GNU projects.

I don't build programs myself other than Emacs, so I have not seen
this.  Perhaps the ideal response would be a change in Automake to
inform users how to see what these commands really do.

Alas, I doubt we have anyone to do that.

  >   So, regardless of whether we implement our own
  > solution for that, I think you should raise that on the autotools
  > forum.

I would like to, even though I fear there is a maintenance crisis there.
What exactly is "the autotools forum"?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-14  4:12           ` Richard Stallman
@ 2022-09-14 11:33             ` Eli Zaretskii
  0 siblings, 0 replies; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-14 11:33 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 14 Sep 2022 00:12:34 -0400
> 
>   >   So, regardless of whether we implement our own
>   > solution for that, I think you should raise that on the autotools
>   > forum.
> 
> I would like to, even though I fear there is a maintenance crisis there.
> What exactly is "the autotools forum"?

I guess bug-automake@gnu.org.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-13 16:11                 ` Eli Zaretskii
@ 2022-09-14 20:02                   ` Alfred M. Szmidt
  2022-09-14 20:05                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 52+ messages in thread
From: Alfred M. Szmidt @ 2022-09-14 20:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rms, luangruo, larsi, sam, emacs-devel

Random idea, not sure if it is possible (easily); what if `make' would
output "note: to get detailed output pass V=1 to make" if `make all`
fails?



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-14 20:02                   ` Alfred M. Szmidt
@ 2022-09-14 20:05                     ` Lars Ingebrigtsen
  2022-09-14 20:47                       ` Gregory Heytings
  0 siblings, 1 reply; 52+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-14 20:05 UTC (permalink / raw)
  To: Alfred M. Szmidt; +Cc: Eli Zaretskii, rms, luangruo, sam, emacs-devel

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Random idea, not sure if it is possible (easily); what if `make' would
> output "note: to get detailed output pass V=1 to make" if `make all`
> fails?

I looked into this earlier -- I wanted it to say something like
"Consider trying "make bootstrap"" (because that'd save people a lot of
time -- reporting the build problem, only to have somebody say that to
them over mail), but I was unable to find a way to make (GNU) Make say
anything in particular on make failures.

But this was a couple of years ago, and perhaps Make has grown this
capability now?  Or I just missed it while reading the Make manual?
Anybody know?




^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-14 20:05                     ` Lars Ingebrigtsen
@ 2022-09-14 20:47                       ` Gregory Heytings
  2022-09-15  7:14                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 52+ messages in thread
From: Gregory Heytings @ 2022-09-14 20:47 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: Alfred M. Szmidt, Eli Zaretskii, rms, luangruo, sam, emacs-devel


>
> I looked into this earlier -- I wanted it to say something like 
> "Consider trying "make bootstrap"" (because that'd save people a lot of 
> time -- reporting the build problem, only to have somebody say that to 
> them over mail), but I was unable to find a way to make (GNU) Make say 
> anything in particular on make failures.
>
> But this was a couple of years ago, and perhaps Make has grown this 
> capability now?  Or I just missed it while reading the Make manual? 
> Anybody know?
>

Does the following do what you want?

diff --git a/Makefile.in b/Makefile.in
index d288bacb9d..67f19e7abd 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -366,6 +366,12 @@ ELN_DESTDIR =

  gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml

+default:
+       $(MAKE) all || $(MAKE) signal_error
+
+signal_error:
+       @echo -e "\nConsider trying \"make bootstrap\"\n"
+
  all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid) 
src-depending-on-lisp

  .PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver




^ permalink raw reply related	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-14 20:47                       ` Gregory Heytings
@ 2022-09-15  7:14                         ` Lars Ingebrigtsen
  2022-09-15  7:28                           ` Gregory Heytings
  2022-09-15 13:13                           ` Ken Brown
  0 siblings, 2 replies; 52+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-15  7:14 UTC (permalink / raw)
  To: Gregory Heytings
  Cc: Alfred M. Szmidt, Eli Zaretskii, rms, luangruo, sam, emacs-devel

Gregory Heytings <gregory@heytings.org> writes:

> Does the following do what you want?
>
> diff --git a/Makefile.in b/Makefile.in
> index d288bacb9d..67f19e7abd 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -366,6 +366,12 @@ ELN_DESTDIR =
>
>  gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml
>
> +default:
> +       $(MAKE) all || $(MAKE) signal_error
> +
> +signal_error:
> +       @echo -e "\nConsider trying \"make bootstrap\"\n"
> +
>  all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid)
>  src-depending-on-lisp

Oh, wow, I didn't even consider doing it this way...  But, yes, that'd
work, I think?  (Except that we should call that rule "all" instead of
"default", since that's the general convention.)




^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15  7:14                         ` Lars Ingebrigtsen
@ 2022-09-15  7:28                           ` Gregory Heytings
  2022-09-15  7:32                             ` Eli Zaretskii
                                               ` (2 more replies)
  2022-09-15 13:13                           ` Ken Brown
  1 sibling, 3 replies; 52+ messages in thread
From: Gregory Heytings @ 2022-09-15  7:28 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: Alfred M. Szmidt, Eli Zaretskii, rms, luangruo, sam, emacs-devel


>> diff --git a/Makefile.in b/Makefile.in
>> index d288bacb9d..67f19e7abd 100644
>> --- a/Makefile.in
>> +++ b/Makefile.in
>> @@ -366,6 +366,12 @@ ELN_DESTDIR =
>>
>>  gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml
>>
>> +default:
>> +       $(MAKE) all || $(MAKE) signal_error
>> +
>> +signal_error:
>> +       @echo -e "\nConsider trying \"make bootstrap\"\n"
>> +
>>  all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid)
>>  src-depending-on-lisp
>
> Oh, wow, I didn't even consider doing it this way...  But, yes, that'd 
> work, I think?  (Except that we should call that rule "all" instead of 
> "default", since that's the general convention.)
>

Okay, I'll wait for other's feedback, and I'll push it, after some more 
testing and after replacing "default" by "all" (and "all" by... something 
else).



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15  7:28                           ` Gregory Heytings
@ 2022-09-15  7:32                             ` Eli Zaretskii
  2022-09-15  7:41                               ` Gregory Heytings
  2022-09-15 14:33                             ` Óscar Fuentes
  2022-09-17 10:46                             ` Gregory Heytings
  2 siblings, 1 reply; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-15  7:32 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: larsi, ams, rms, luangruo, sam, emacs-devel

> Date: Thu, 15 Sep 2022 07:28:09 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: "Alfred M. Szmidt" <ams@gnu.org>, Eli Zaretskii <eliz@gnu.org>, 
>     rms@gnu.org, luangruo@yahoo.com, sam@gentoo.org, emacs-devel@gnu.org
> 
> 
> >> diff --git a/Makefile.in b/Makefile.in
> >> index d288bacb9d..67f19e7abd 100644
> >> --- a/Makefile.in
> >> +++ b/Makefile.in
> >> @@ -366,6 +366,12 @@ ELN_DESTDIR =
> >>
> >>  gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml
> >>
> >> +default:
> >> +       $(MAKE) all || $(MAKE) signal_error
> >> +
> >> +signal_error:
> >> +       @echo -e "\nConsider trying \"make bootstrap\"\n"
> >> +
> >>  all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid)
> >>  src-depending-on-lisp
> >
> > Oh, wow, I didn't even consider doing it this way...  But, yes, that'd 
> > work, I think?  (Except that we should call that rule "all" instead of 
> > "default", since that's the general convention.)
> >
> 
> Okay, I'll wait for other's feedback, and I'll push it, after some more 
> testing and after replacing "default" by "all" (and "all" by... something 
> else).

If this is what we are going to do, please also add to the message the
bit about V=1.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15  7:32                             ` Eli Zaretskii
@ 2022-09-15  7:41                               ` Gregory Heytings
  2022-09-15  9:07                                 ` Eli Zaretskii
  0 siblings, 1 reply; 52+ messages in thread
From: Gregory Heytings @ 2022-09-15  7:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, ams, rms, luangruo, sam, emacs-devel


>
> If this is what we are going to do,
>

I'm not sure, does that mean you have objections?

>
> please also add to the message the bit about V=1.
>

Okay, I'll do that.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15  7:41                               ` Gregory Heytings
@ 2022-09-15  9:07                                 ` Eli Zaretskii
  0 siblings, 0 replies; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-15  9:07 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: larsi, ams, rms, luangruo, sam, emacs-devel

> Date: Thu, 15 Sep 2022 07:41:07 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, ams@gnu.org, rms@gnu.org, luangruo@yahoo.com, 
>     sam@gentoo.org, emacs-devel@gnu.org
> 
> > If this is what we are going to do,
> >
> 
> I'm not sure, does that mean you have objections?

No objections from me.  But maybe others will.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15  7:14                         ` Lars Ingebrigtsen
  2022-09-15  7:28                           ` Gregory Heytings
@ 2022-09-15 13:13                           ` Ken Brown
  2022-09-15 14:01                             ` Gregory Heytings
  1 sibling, 1 reply; 52+ messages in thread
From: Ken Brown @ 2022-09-15 13:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Gregory Heytings
  Cc: Alfred M. Szmidt, Eli Zaretskii, rms, luangruo, sam, emacs-devel

On 9/15/2022 3:14 AM, Lars Ingebrigtsen wrote:
> Gregory Heytings <gregory@heytings.org> writes:
> 
>> Does the following do what you want?
>>
>> diff --git a/Makefile.in b/Makefile.in
>> index d288bacb9d..67f19e7abd 100644
>> --- a/Makefile.in
>> +++ b/Makefile.in
>> @@ -366,6 +366,12 @@ ELN_DESTDIR =
>>
>>   gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml
>>
>> +default:
>> +       $(MAKE) all || $(MAKE) signal_error
>> +
>> +signal_error:
>> +       @echo -e "\nConsider trying \"make bootstrap\"\n"

Shouldn't you also exit with an error code?  Otherwise you break scripts that 
depend on knowing whether 'make' succeeded.

Ken



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15 13:13                           ` Ken Brown
@ 2022-09-15 14:01                             ` Gregory Heytings
  0 siblings, 0 replies; 52+ messages in thread
From: Gregory Heytings @ 2022-09-15 14:01 UTC (permalink / raw)
  To: Ken Brown
  Cc: Lars Ingebrigtsen, Alfred M. Szmidt, Eli Zaretskii, rms, luangruo,
	sam, emacs-devel


>
> Shouldn't you also exit with an error code?  Otherwise you break scripts 
> that depend on knowing whether 'make' succeeded.
>

Yes, the code was just a short proof of concept.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15  7:28                           ` Gregory Heytings
  2022-09-15  7:32                             ` Eli Zaretskii
@ 2022-09-15 14:33                             ` Óscar Fuentes
  2022-09-15 16:04                               ` Gregory Heytings
  2022-09-17 10:46                             ` Gregory Heytings
  2 siblings, 1 reply; 52+ messages in thread
From: Óscar Fuentes @ 2022-09-15 14:33 UTC (permalink / raw)
  To: emacs-devel

Gregory Heytings <gregory@heytings.org> writes:

>>> diff --git a/Makefile.in b/Makefile.in
>>> index d288bacb9d..67f19e7abd 100644
>>> --- a/Makefile.in
>>> +++ b/Makefile.in
>>> @@ -366,6 +366,12 @@ ELN_DESTDIR =
>>>
>>>  gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml
>>>
>>> +default:
>>> +       $(MAKE) all || $(MAKE) signal_error
>>> +
>>> +signal_error:
>>> +       @echo -e "\nConsider trying \"make bootstrap\"\n"
>>> +
>>>  all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid)
>>>  src-depending-on-lisp

Wouldn't this result in `make' returning success when the build failed?




^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15 14:33                             ` Óscar Fuentes
@ 2022-09-15 16:04                               ` Gregory Heytings
  0 siblings, 0 replies; 52+ messages in thread
From: Gregory Heytings @ 2022-09-15 16:04 UTC (permalink / raw)
  To: Óscar Fuentes; +Cc: emacs-devel


>
> Wouldn't this result in `make' returning success when the build failed?
>

Yes, as I said a few hours ago that code was only a short proof of 
concept.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-15  7:28                           ` Gregory Heytings
  2022-09-15  7:32                             ` Eli Zaretskii
  2022-09-15 14:33                             ` Óscar Fuentes
@ 2022-09-17 10:46                             ` Gregory Heytings
  2022-09-17 11:20                               ` Alan Mackenzie
  2022-09-18 10:37                               ` Lars Ingebrigtsen
  2 siblings, 2 replies; 52+ messages in thread
From: Gregory Heytings @ 2022-09-17 10:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel

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


Complete patch attached, comments welcome.

I added a (minimal) sanity check, too.  I remember at least one case when 
make "failed to fail", it returned 0 even though the build did in fact not 
succeed.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Display-a-help-message-when-building-Emacs-failed.patch --]
[-- Type: text/x-diff; name=Display-a-help-message-when-building-Emacs-failed.patch, Size: 2459 bytes --]

From 8cab514b4499b99f3c2ae07fa345b54c4ecc5823 Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Sat, 17 Sep 2022 10:39:03 +0000
Subject: [PATCH] Display a help message when building Emacs failed.

* Makefile.in (actual-all): New target, replacing the former all target.
(advice-on-failure, sanity-check): New targets.
(all): Use the new targets.
---
 Makefile.in | 42 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/Makefile.in b/Makefile.in
index 3f811ea60f..2e518de348 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -366,7 +366,47 @@ ELN_DESTDIR =
 
 gsettings_SCHEMAS = etc/org.gnu.emacs.defaults.gschema.xml
 
-all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid) src-depending-on-lisp
+all:
+	$(MAKE) actual-all || $(MAKE) advice-on-failure exit-status=$$?
+	$(MAKE) sanity-check
+
+.PHONY: actual-all advice-on-failure sanity-check
+
+actual-all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid) src-depending-on-lisp
+
+advice-on-failure:
+	@echo
+	@echo "  Make failed with exit status ${exit-status}."
+	@cat Makefile | \
+	  sed -n '/^# ADVICE-ON-FAILURE-BEGIN/,$${p;/^# ADVICE-ON-FAILURE-END/q};' | \
+	  sed 's/^# //' | grep -v '^ADVICE-ON-FAILURE-'
+	@echo
+	@exit ${exit-status}
+
+# ADVICE-ON-FAILURE-BEGIN
+#   You might consider to:
+#   - run "make bootstrap", which might fix the problem
+#   - run "git clean -fdx" and run "make" again, which might fix
+#     the problem if it was not fixed by "make bootstrap"
+#     !BEWARE! "git clean -fdx" restores the local repository in its
+#     !BEWARE! pristine state, it deletes all local changes and all
+#     !BEWARE! untracked files
+#   - run "make V=1", which displays the full commandes invoked by
+#     make, to further investigate the problem
+# ADVICE-ON-FAILURE-END
+
+sanity-check:
+	@v=$$(src/emacs${EXEEXT} --batch --eval \
+	  '(progn (defun f (n) (if (= 0 n) 1 (* n (f (- n 1))))) (princ (f 10)))' \
+	  2> /dev/null); \
+	[ "X$$v" == "X3628800" ] && exit 0; \
+	echo; \
+	echo "  Make succeeded, but Emacs is not functional."; \
+	cat Makefile | \
+	  sed -n '/^# ADVICE-ON-FAILURE-BEGIN/,$${p;/^# ADVICE-ON-FAILURE-END/q};' | \
+	  sed 's/^# //' | grep -v '^ADVICE-ON-FAILURE-'; \
+	echo; \
+	exit 1
 
 .PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force-ns-self-contained etc-emacsver
 
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-17 10:46                             ` Gregory Heytings
@ 2022-09-17 11:20                               ` Alan Mackenzie
  2022-09-17 16:41                                 ` Michael Welsh Duggan
  2022-09-17 22:58                                 ` Gregory Heytings
  2022-09-18 10:37                               ` Lars Ingebrigtsen
  1 sibling, 2 replies; 52+ messages in thread
From: Alan Mackenzie @ 2022-09-17 11:20 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Lars Ingebrigtsen, Eli Zaretskii, emacs-devel

Hello, Gregory.

On Sat, Sep 17, 2022 at 10:46:24 +0000, Gregory Heytings wrote:

> Complete patch attached, comments welcome.

Just a small point in English usage:

> I added a (minimal) sanity check, too.  I remember at least one case when 
> make "failed to fail", it returned 0 even though the build did in fact not 
> succeed.

> +
> +# ADVICE-ON-FAILURE-BEGIN
> +#   You might consider to:
> +#   - run "make bootstrap", which might fix the problem
> +#   - run "git clean -fdx" and run "make" again, which might fix
> +#     the problem if it was not fixed by "make bootstrap"
> +#     !BEWARE! "git clean -fdx" restores the local repository in its
> +#     !BEWARE! pristine state, it deletes all local changes and all
> +#     !BEWARE! untracked files
> +#   - run "make V=1", which displays the full commandes invoked by
> +#     make, to further investigate the problem
> +# ADVICE-ON-FAILURE-END
> +

The verb "consider" takes a gerund (or noun), not an infinitive.  So the
above really ought to be:

    You might consider:
    - running ....

, with the other "run"s being changed to "running", too.  Alternatively,
one could use instead the verb "try", which can take an infinitive (or a
gerund or noun ;-).

-- 
Alan Mackenzie (Nuremberg, Germany).



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-17 11:20                               ` Alan Mackenzie
@ 2022-09-17 16:41                                 ` Michael Welsh Duggan
  2022-09-17 22:59                                   ` Gregory Heytings
  2022-09-17 22:58                                 ` Gregory Heytings
  1 sibling, 1 reply; 52+ messages in thread
From: Michael Welsh Duggan @ 2022-09-17 16:41 UTC (permalink / raw)
  To: Alan Mackenzie
  Cc: Gregory Heytings, Lars Ingebrigtsen, Eli Zaretskii, emacs-devel

Alan Mackenzie <acm@muc.de> writes:

> Hello, Gregory.
>
> On Sat, Sep 17, 2022 at 10:46:24 +0000, Gregory Heytings wrote:
>
>> Complete patch attached, comments welcome.
>
> Just a small point in English usage:
>
>> I added a (minimal) sanity check, too.  I remember at least one case when 
>> make "failed to fail", it returned 0 even though the build did in fact not 
>> succeed.
>
>> +
>> +# ADVICE-ON-FAILURE-BEGIN
>> +#   You might consider to:
>> +#   - run "make bootstrap", which might fix the problem
>> +#   - run "git clean -fdx" and run "make" again, which might fix
>> +#     the problem if it was not fixed by "make bootstrap"
>> +#     !BEWARE! "git clean -fdx" restores the local repository in its
>> +#     !BEWARE! pristine state, it deletes all local changes and all
>> +#     !BEWARE! untracked files
>> +#   - run "make V=1", which displays the full commandes invoked by
>> +#     make, to further investigate the problem
>> +# ADVICE-ON-FAILURE-END
>> +
>
> The verb "consider" takes a gerund (or noun), not an infinitive.  So the
> above really ought to be:
>
>     You might consider:
>     - running ....
>
> , with the other "run"s being changed to "running", too.  Alternatively,
> one could use instead the verb "try", which can take an infinitive (or a
> gerund or noun ;-).

Also, for completeness sake, "commands" instead of "commandes".

-- 
Michael Welsh Duggan
(md5i@md5i.com)



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-17 11:20                               ` Alan Mackenzie
  2022-09-17 16:41                                 ` Michael Welsh Duggan
@ 2022-09-17 22:58                                 ` Gregory Heytings
  1 sibling, 0 replies; 52+ messages in thread
From: Gregory Heytings @ 2022-09-17 22:58 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: Lars Ingebrigtsen, Eli Zaretskii, emacs-devel


>
> The verb "consider" takes a gerund (or noun), not an infinitive.  So the 
> above really ought to be:
>
> You might consider:
> - running ....
>
> with the other "run"s being changed to "running", too.  Alternatively, 
> one could use instead the verb "try", which can take an infinitive (or a 
> gerund or noun ;-).
>

Indeed, thanks!



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-17 16:41                                 ` Michael Welsh Duggan
@ 2022-09-17 22:59                                   ` Gregory Heytings
  0 siblings, 0 replies; 52+ messages in thread
From: Gregory Heytings @ 2022-09-17 22:59 UTC (permalink / raw)
  To: Michael Welsh Duggan
  Cc: Alan Mackenzie, Lars Ingebrigtsen, Eli Zaretskii, emacs-devel


>
> Also, for completeness sake, "commands" instead of "commandes".
>

Thanks, typo fixed!



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-17 10:46                             ` Gregory Heytings
  2022-09-17 11:20                               ` Alan Mackenzie
@ 2022-09-18 10:37                               ` Lars Ingebrigtsen
  2022-09-18 11:38                                 ` Gerd Möllmann
  2022-09-18 21:39                                 ` Gregory Heytings
  1 sibling, 2 replies; 52+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-18 10:37 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Eli Zaretskii, emacs-devel

Gregory Heytings <gregory@heytings.org> writes:

> Complete patch attached, comments welcome.

Looks good to me (adjusting for comments from others), so feel free to
push when you're satisfied with the patch.  But one bikeshedding
opportunity:

> +# ADVICE-ON-FAILURE-BEGIN
> +#   You might consider to:
> +#   - run "make bootstrap", which might fix the problem
> +#   - run "git clean -fdx" and run "make" again, which might fix
> +#     the problem if it was not fixed by "make bootstrap"
> +#     !BEWARE! "git clean -fdx" restores the local repository in its
> +#     !BEWARE! pristine state, it deletes all local changes and all
> +#     !BEWARE! untracked files

I wonder whether this could be a two part thing?  That is, have just
"make" say the bit about "make bootstrap" and "V=1", and say the bit
about "git clean" if "make bootstrap" fails?  (Because we don't really
want to recommend to people that they say "git clean" unless they really
have to.)

But if that's too much work, then it's fine as it is.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 10:37                               ` Lars Ingebrigtsen
@ 2022-09-18 11:38                                 ` Gerd Möllmann
  2022-09-18 11:53                                   ` Andreas Schwab
  2022-09-18 21:39                                 ` Gregory Heytings
  1 sibling, 1 reply; 52+ messages in thread
From: Gerd Möllmann @ 2022-09-18 11:38 UTC (permalink / raw)
  To: larsi; +Cc: eliz, emacs-devel, gregory

 > +#     !BEWARE! "git clean -fdx" restores the local repository in its
 > +#     !BEWARE! pristine state, it deletes all local changes and all
 > +#     !BEWARE! untracked files

BTW, I don't think that's true, if local changes means changes to 
git-controlled files.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 11:38                                 ` Gerd Möllmann
@ 2022-09-18 11:53                                   ` Andreas Schwab
  2022-09-18 12:05                                     ` Gerd Möllmann
  2022-09-18 16:40                                     ` Gregory Heytings
  0 siblings, 2 replies; 52+ messages in thread
From: Andreas Schwab @ 2022-09-18 11:53 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: larsi, eliz, emacs-devel, gregory

On Sep 18 2022, Gerd Möllmann wrote:

>> +#     !BEWARE! "git clean -fdx" restores the local repository in its
>> +#     !BEWARE! pristine state, it deletes all local changes and all
>> +#     !BEWARE! untracked files
>
> BTW, I don't think that's true, if local changes means changes to
> git-controlled files.

Right, git clean is only about untracked files.  To remove changes to
tracked files, use git checkout.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 11:53                                   ` Andreas Schwab
@ 2022-09-18 12:05                                     ` Gerd Möllmann
  2022-09-18 13:48                                       ` Robert Pluim
  2022-09-18 16:40                                     ` Gregory Heytings
  1 sibling, 1 reply; 52+ messages in thread
From: Gerd Möllmann @ 2022-09-18 12:05 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: larsi, eliz, emacs-devel, gregory

On 22-09-18 13:53 , Andreas Schwab wrote:

> Right, git clean is only about untracked files.  To remove changes to
> tracked files, use git checkout.

Or reset it the --hard way :-).




^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 12:05                                     ` Gerd Möllmann
@ 2022-09-18 13:48                                       ` Robert Pluim
  0 siblings, 0 replies; 52+ messages in thread
From: Robert Pluim @ 2022-09-18 13:48 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Andreas Schwab, larsi, eliz, emacs-devel, gregory

>>>>> On Sun, 18 Sep 2022 14:05:34 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:

    Gerd> On 22-09-18 13:53 , Andreas Schwab wrote:
    >> Right, git clean is only about untracked files.  To remove changes to
    >> tracked files, use git checkout.

    Gerd> Or reset it the --hard way :-).

Whenever Iʼm tempted to pass --hard to 'git reset', I always 'git
stash' first 😀

Robert
-- 



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 11:53                                   ` Andreas Schwab
  2022-09-18 12:05                                     ` Gerd Möllmann
@ 2022-09-18 16:40                                     ` Gregory Heytings
  2022-09-18 16:59                                       ` Andreas Schwab
  1 sibling, 1 reply; 52+ messages in thread
From: Gregory Heytings @ 2022-09-18 16:40 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Gerd Möllmann, larsi, eliz, emacs-devel


>>> +#     !BEWARE! "git clean -fdx" restores the local repository in its
>>> +#     !BEWARE! pristine state, it deletes all local changes and all
>>> +#     !BEWARE! untracked files
>>
>> BTW, I don't think that's true, if local changes means changes to 
>> git-controlled files.
>
> Right, git clean is only about untracked files.
>

Indeed, I meant "to untracked files" with "local changes", that wasn't 
clear at all.  Thanks, fixed.

>
> To remove changes to tracked files, use git checkout.
>

No, git checkout doesn't remove changes to tracked files.  To remove 
changes to tracked files, use git reset --hard, or (safer) git stash.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 16:40                                     ` Gregory Heytings
@ 2022-09-18 16:59                                       ` Andreas Schwab
  2022-09-18 21:50                                         ` Gregory Heytings
  0 siblings, 1 reply; 52+ messages in thread
From: Andreas Schwab @ 2022-09-18 16:59 UTC (permalink / raw)
  To: Gregory Heytings; +Cc: Gerd Möllmann, larsi, eliz, emacs-devel

On Sep 18 2022, Gregory Heytings wrote:

> No, git checkout doesn't remove changes to tracked files.

Yes, it does.  git checkout HEAD <pathspec> overwrites the matching
files with contents from the HEAD commit.  In that operation mode it is
similar to git reset --hard.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 10:37                               ` Lars Ingebrigtsen
  2022-09-18 11:38                                 ` Gerd Möllmann
@ 2022-09-18 21:39                                 ` Gregory Heytings
  1 sibling, 0 replies; 52+ messages in thread
From: Gregory Heytings @ 2022-09-18 21:39 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel

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


>
> Looks good to me (adjusting for comments from others), so feel free to 
> push when you're satisfied with the patch.
>

Done.

>
> I wonder whether this could be a two part thing?
>

It could! 😃

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 16:59                                       ` Andreas Schwab
@ 2022-09-18 21:50                                         ` Gregory Heytings
  2022-09-19 17:20                                           ` chad
  0 siblings, 1 reply; 52+ messages in thread
From: Gregory Heytings @ 2022-09-18 21:50 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Gerd Möllmann, larsi, eliz, emacs-devel


>>> To remove changes to tracked files, use git checkout.
>>
>> No, git checkout doesn't remove changes to tracked files.
>
> Yes, it does.  git checkout HEAD <pathspec> overwrites the matching 
> files with contents from the HEAD commit.  In that operation mode it is 
> similar to git reset --hard.
>

With <pathspec>s, indeed, but in this discussion we were mentioning 
commands that operate on all files at once.

(On a side note, it is preferable to use git restore <pathspec> instead of 
git checkout <pathspec>.)



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-18 21:50                                         ` Gregory Heytings
@ 2022-09-19 17:20                                           ` chad
  2022-09-19 17:25                                             ` Eli Zaretskii
  2022-09-19 20:42                                             ` Stefan Monnier
  0 siblings, 2 replies; 52+ messages in thread
From: chad @ 2022-09-19 17:20 UTC (permalink / raw)
  To: Gregory Heytings
  Cc: Andreas Schwab, Gerd Möllmann, Lars Ingebrigtsen,
	Eli Zaretskii, EMACS development team

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

If you're already breaking it into parts: how hard would it be to have the
Makefile rerun with a message and V=1 automatically on failure (and
obviously avoid make-looping)? My experience diving into the intricacies of
make is quite dated (old enough to vote now), and was so pleasant that we
invented our own replacement which I recall was pretty common at the time).
My first thought was to use a flag-dotfile, and my second thought was that
there must be a better way these days. :-)

[-- Attachment #2: Type: text/html, Size: 514 bytes --]

^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-19 17:20                                           ` chad
@ 2022-09-19 17:25                                             ` Eli Zaretskii
  2022-09-19 20:42                                             ` Stefan Monnier
  1 sibling, 0 replies; 52+ messages in thread
From: Eli Zaretskii @ 2022-09-19 17:25 UTC (permalink / raw)
  To: chad; +Cc: gregory, schwab, gerd.moellmann, larsi, emacs-devel

> From: chad <yandros@gmail.com>
> Date: Mon, 19 Sep 2022 13:20:29 -0400
> Cc: Andreas Schwab <schwab@linux-m68k.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, 
> 	Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> If you're already breaking it into parts: how hard would it be to have the Makefile rerun with a message and
> V=1 automatically on failure (and obviously avoid make-looping)?

Absolutely not!  99% the problem is crystal-clear from the error
messages, and there's absolutely no reason to re-run the same command
once more, and with much more voluminous output on top of that.



^ permalink raw reply	[flat|nested] 52+ messages in thread

* Re: src/Makefile unhelpful
  2022-09-19 17:20                                           ` chad
  2022-09-19 17:25                                             ` Eli Zaretskii
@ 2022-09-19 20:42                                             ` Stefan Monnier
  1 sibling, 0 replies; 52+ messages in thread
From: Stefan Monnier @ 2022-09-19 20:42 UTC (permalink / raw)
  To: chad
  Cc: Gregory Heytings, Andreas Schwab, Gerd Möllmann,
	Lars Ingebrigtsen, Eli Zaretskii, EMACS development team

> If you're already breaking it into parts: how hard would it be to have the
> Makefile rerun with a message and V=1 automatically on failure (and
> obviously avoid make-looping)?

We could also try and recognize the common sources of those failures and
try and fix auto-fix them.  E.g. check the emacs-devel archive for
recent reports matching this error.  Can't be hard with today's
wonderful AI thingies.
Might even get a conference paper out of it.


        Stefan "no, please don't go there"




^ permalink raw reply	[flat|nested] 52+ messages in thread

end of thread, other threads:[~2022-09-19 20:42 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-09-07  2:19 src/Makefile unhelpful Richard Stallman
2022-09-07  2:38 ` Po Lu
2022-09-07  2:41 ` Eli Zaretskii
2022-09-08  3:00   ` Richard Stallman
2022-09-08  4:51     ` Sam James
2022-09-11  3:38       ` Richard Stallman
2022-09-11  5:34         ` Eli Zaretskii
2022-09-11  9:57           ` Lars Ingebrigtsen
2022-09-11 11:59             ` Po Lu
2022-09-11 12:07               ` Eli Zaretskii
2022-09-11 12:16                 ` Lars Ingebrigtsen
2022-09-13  4:07               ` Richard Stallman
2022-09-13 16:11                 ` Eli Zaretskii
2022-09-14 20:02                   ` Alfred M. Szmidt
2022-09-14 20:05                     ` Lars Ingebrigtsen
2022-09-14 20:47                       ` Gregory Heytings
2022-09-15  7:14                         ` Lars Ingebrigtsen
2022-09-15  7:28                           ` Gregory Heytings
2022-09-15  7:32                             ` Eli Zaretskii
2022-09-15  7:41                               ` Gregory Heytings
2022-09-15  9:07                                 ` Eli Zaretskii
2022-09-15 14:33                             ` Óscar Fuentes
2022-09-15 16:04                               ` Gregory Heytings
2022-09-17 10:46                             ` Gregory Heytings
2022-09-17 11:20                               ` Alan Mackenzie
2022-09-17 16:41                                 ` Michael Welsh Duggan
2022-09-17 22:59                                   ` Gregory Heytings
2022-09-17 22:58                                 ` Gregory Heytings
2022-09-18 10:37                               ` Lars Ingebrigtsen
2022-09-18 11:38                                 ` Gerd Möllmann
2022-09-18 11:53                                   ` Andreas Schwab
2022-09-18 12:05                                     ` Gerd Möllmann
2022-09-18 13:48                                       ` Robert Pluim
2022-09-18 16:40                                     ` Gregory Heytings
2022-09-18 16:59                                       ` Andreas Schwab
2022-09-18 21:50                                         ` Gregory Heytings
2022-09-19 17:20                                           ` chad
2022-09-19 17:25                                             ` Eli Zaretskii
2022-09-19 20:42                                             ` Stefan Monnier
2022-09-18 21:39                                 ` Gregory Heytings
2022-09-15 13:13                           ` Ken Brown
2022-09-15 14:01                             ` Gregory Heytings
2022-09-11 15:16           ` Werner LEMBERG
2022-09-12  4:35             ` Richard Stallman
2022-09-08  6:14     ` Eli Zaretskii
2022-09-08  7:29       ` Andreas Schwab
2022-09-08 13:18       ` Stefan Monnier
2022-09-11  3:38       ` Richard Stallman
2022-09-11  5:42         ` Eli Zaretskii
2022-09-14  4:12           ` Richard Stallman
2022-09-14 11:33             ` Eli Zaretskii
2022-09-07  3:11 ` Sam James

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.