bug-make
[Top][All Lists]
Advanced

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

Re: GNU make troubleshooting


From: Eli Zaretskii
Subject: Re: GNU make troubleshooting
Date: Sun, 27 Aug 2023 16:33:34 +0300

> From: Paul Smith <psmith@gnu.org>
> Cc: bruno@clisp.org, bug-make@gnu.org
> Date: Sun, 27 Aug 2023 09:16:59 -0400
> 
> On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote:
> > This checklist is very useful, but to make it even more useful, it
> > lacks two things:
> > 
> >  . an example of error message that indicates each kind of problem
> >  . a cross-reference to where the details are
> 
> There is a menu of links to each type of error just below the list,
> because this is a chapter node in texinfo; like:

Yes, I know.  But a single @xref after each item in the "checklist"
will be a great help, IMO.

> > I would suggest to add here a short description of how to interpret
> > these exit codes.  The codes 2 and -1 are very frequent, so maybe
> > explain them right here.
> 
> What should we explain about them?

That error code 2 means file not found, and -1 means a command was not
found or completely failed to run.  It is easy to show a couple of
examples for each one, we see those every day.

> > Removing @ is not always enough.  Many makefiles nowadays need you to
> > say "make V=1" to override the default verbosity level.  I suggest to
> > mention that.
> 
> What does "V=1" do, that removing the "@" doesn't do?

It shows the full command instead of something like

  CC foo.o

> I'm not familiar with any makefile where "V=1" enables "extra"
> debugging: normally it just disables "@".  I would prefer to avoid
> adding descriptions that depend on how specific makefiles are
> implemented, unless that is also described in the GNU Make manual.

The V=1 stuff is nowadays standard in the GNU project's makefiles, so
I think it would be a good addition.  Of course, it's your call.



reply via email to

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