src/Makefile unhelpful

src/Makefile unhelpful

[Richard Stallman]

[[[ 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)

Re: src/Makefile unhelpful

[Po Lu]

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.

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Sam James]

[-- 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 --]

Re: src/Makefile unhelpful

[Richard Stallman]

[[[ 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)

Re: src/Makefile unhelpful

[Sam James]

[-- 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 --]

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Andreas Schwab]

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

Re: src/Makefile unhelpful

[Stefan Monnier]

> 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

Re: src/Makefile unhelpful

[Richard Stallman]

[[[ 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)

Re: src/Makefile unhelpful

[Richard Stallman]

[[[ 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)

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Lars Ingebrigtsen]

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.

Re: src/Makefile unhelpful

[Po Lu]

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.

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Lars Ingebrigtsen]

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.

Re: src/Makefile unhelpful

[Werner LEMBERG]

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

Re: src/Makefile unhelpful

[Richard Stallman]

[[[ 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)

Re: src/Makefile unhelpful

[Richard Stallman]

[[[ 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)

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Richard Stallman]

[[[ 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)

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Alfred M. Szmidt]

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?

Re: src/Makefile unhelpful

[Lars Ingebrigtsen]

"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?

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[Lars Ingebrigtsen]

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

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Ken Brown]

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

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[Óscar Fuentes]

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?

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[Alan Mackenzie]

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

Re: src/Makefile unhelpful

[Michael Welsh Duggan]

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)

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Thanks, typo fixed!

Re: src/Makefile unhelpful

[Lars Ingebrigtsen]

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.

Re: src/Makefile unhelpful

[Gerd Möllmann]

 > +#     !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.

Re: src/Makefile unhelpful

[Andreas Schwab]

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

Re: src/Makefile unhelpful

[Gerd Möllmann]

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

Re: src/Makefile unhelpful

[Robert Pluim]

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

Re: src/Makefile unhelpful

[Gregory Heytings]

>>> +#     !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.

Re: src/Makefile unhelpful

[Andreas Schwab]

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

Re: src/Makefile unhelpful

[Gregory Heytings]

[-- 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! 😃

Re: src/Makefile unhelpful

[Gregory Heytings]

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

Re: src/Makefile unhelpful

[chad]

[-- 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 --]

Re: src/Makefile unhelpful

[Eli Zaretskii]

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

Re: src/Makefile unhelpful

[Stefan Monnier]

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