Re: GNU make troubleshooting

On Sun, 2023-09-03 at 02:24 +0200, Alejandro Colomar wrote: > Let's add one more: > > -  Make has problems running the SHELL This is an interesting situation but I don't think it belongs in the GNU make manual. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org

Re: GNU make troubleshooting

Hi Paul, On 2023-08-26 18:48, Paul Smith wrote: > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. > > I think the outline you provided earlier, Bruno, has the problem that a > lot of it isn't really about troublesho

Re: GNU make troubleshooting

On Tue, 2023-08-29 at 09:44 -0400, David Boyce wrote: > - I find it interesting that there's no mention of -n which seems > like a bog-standard, POSIX-compliant, debugging method. It's also > another way of getting around @. Simplistic but worth mentioning > IMHO. I rarely use -n, personally. Als

Re: GNU make troubleshooting

A few thoughts, mostly on the shell/recipe end of things: - I find it interesting that there's no mention of -n which seems like a bog-standard, POSIX-compliant, debugging method. It's also another way of getting around @. Simplistic but worth mentioning IMHO. - I wonder why there's so much empha

Re: GNU make troubleshooting

Hi Paul, On 2023-08-27 15:52, Paul Smith wrote: > On Sun, 2023-08-27 at 15:47 +0200, Alejandro Colomar wrote: >> In fact, I'm going to define .SILENT always in the Linux man-pages, >> since V=1 is just an unnecessary duplicate for --degub=print. >> I'll make V=1 only have the effect of redirecting

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 15:47 +0200, Alejandro Colomar wrote: > In fact, I'm going to define .SILENT always in the Linux man-pages, > since V=1 is just an unnecessary duplicate for --degub=print. > I'll make V=1 only have the effect of redirecting stderr of certain > programs. Just be aware that --d

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 16:33 +0300, Eli Zaretskii wrote: > 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. That might be true in Windows but it's not the case

Re: GNU make troubleshooting

On 2023-08-27 15:35, Alejandro Colomar wrote: > On 2023-08-27 15:33, Paul Smith wrote: >> On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: >>> Yes, that's a good idea to mention .SILENT. >> >> Actually I think I will simply recomment using --debug=print instead as >> that's simpler. > > LGTM.

Re: GNU make troubleshooting

On 2023-08-27 15:33, Paul Smith wrote: > On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: >> Yes, that's a good idea to mention .SILENT. > > Actually I think I will simply recomment using --debug=print instead as > that's simpler. LGTM. That's much better, as you don't modify the Makefile, a

Re: GNU make troubleshooting

> From: Paul Smith > Cc: br...@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

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 09:26 -0400, Paul Smith wrote: > Yes, that's a good idea to mention .SILENT. Actually I think I will simply recomment using --debug=print instead as that's simpler. -- Paul D. Smith Find some GNU make tips at: https://www.gnu.org http://mak

Re: GNU make troubleshooting

On Sun, 2023-08-27 at 15:21 +0200, Alejandro Colomar wrote: > Maybe mention that removing .SILENT: would be necessary, if > it is defined.  Here's what the Linux man-pages makefiles do. Yes, that's a good idea to mention .SILENT. I really don't want to get into documenting all the different ways

Re: GNU make troubleshooting

Hi Paul, On 2023-08-27 15:16, Paul Smith wrote: > On Sun, 2023-08-27 at 08:51 +0300, Eli Zaretskii wrote:> >> 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, th

Re: GNU make troubleshooting

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

Re: GNU make troubleshooting

Hi Paul, On 2023-08-26 18:48, Paul Smith wrote: > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. > > I think the outline you provided earlier, Bruno, has the problem that a > lot of it isn't really about troublesho

Re: GNU make troubleshooting

> From: Paul Smith > Date: Sat, 26 Aug 2023 12:48:05 -0400 > > I added a new appendix to the GNU make manual for troubleshooting help; > I haven't pushed it yet. See below. Comments welcome. Thanks, this sounds very useful. Some comments below. >If you have problems with GNU Make, first

Re: GNU make troubleshooting

I added a new appendix to the GNU make manual for troubleshooting help; I haven't pushed it yet. See below. Comments welcome. I think the outline you provided earlier, Bruno, has the problem that a lot of it isn't really about troubleshooting per se, it's about how to write makefiles in general.

Re: wildcard and globstar (was: GNU make troubleshooting)

On Sun, Jul 16, 2023 at 4:59 PM Alejandro Colomar wrote: > I'm still interested in globstar support, though. It would make that > line shorter and more robust. Maybe you could add an option > --glob=globstar or similar to enable support. gmake does not keep its own impl of glob. It uses a copy

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > I believe these two user goals are so different; they belong in different > > chapters. > ... > In other words, i don't see a chapter on how to avoid big debug output > without optimizing the makefile. Wait a second. "How to avoid big debug output?" is not one of the pr

Re: GNU make troubleshooting

On Sat, 2023-07-15 at 11:28 -0400, Dmitry Goncharov wrote: > Appendix A Debug Output. Thanks for this Dmitry; I spent some time this weekend working on a new section of the manual that would overlap with this. However I will definitely examine your patch and make sure the points you (and everyone

Re: GNU make troubleshooting

On 2023-07-16 22:14, Philip Guenther wrote: > I just put this at the very end of top makefile: > > ${MAKEFILE_LIST}: ; Hmm, that's giving me another good idea. Luckily, I haven't pushed the changes I had done yet. Thanks! Alex > > Philip Guenther -- GPG ke

Re: wildcard and globstar (was: GNU make troubleshooting)

Hi! On 2023-07-16 18:31, Dmitry Goncharov wrote: > On Sun, Jul 16, 2023 at 10:49 AM Alejandro Colomar wrote: >> I guess I'd need some kind of globstar support in GNU Make to be able >> to use that > > Do you mean you need to find .mk files in subdirectories at different > depth levels? > mk:=$(w

Re: GNU make troubleshooting

I just put this at the very end of top makefile: ${MAKEFILE_LIST}: ; Philip Guenther On Sun, Jul 16, 2023 at 12:25 PM Torbjorn SVENSSON < torbjorn.svens...@foss.st.com> wrote: > > > On 2023-07-16 15:58, Alejandro Colomar wrote: > > Wow! That's a great help for debugging the Linux man-pages's m

Re: GNU make troubleshooting

On 2023-07-16 15:58, Alejandro Colomar wrote: Wow! That's a great help for debugging the Linux man-pages's makefiles, which don't need to be remade. It was very painful to me to ignore so much make -d output. I applied the following patch, and it works like a charm.

Re: wildcard and globstar (was: GNU make troubleshooting)

On Sun, Jul 16, 2023 at 10:49 AM Alejandro Colomar wrote: > I guess I'd need some kind of globstar support in GNU Make to be able > to use that Do you mean you need to find .mk files in subdirectories at different depth levels? mk:=$(wildcard */*/*.mk */*.mk *.mk) regards, Dmitry

wildcard and globstar (was: GNU make troubleshooting)

On 2023-07-16 16:17, Dmitry Goncharov wrote: > Como estas, Alex? Muy bien, y tu? =) > > On Sun, Jul 16, 2023 at 9:59 AM Alejandro Colomar wrote: >> I applied the following patch > >>

Re: GNU make troubleshooting

Como estas, Alex? On Sun, Jul 16, 2023 at 9:59 AM Alejandro Colomar wrote: > I applied the following patch > Glad you liked it. Rather than `find -type f...` (which is painfully slo

Re: GNU make troubleshooting

Hi Dmitry! On 2023-07-15 17:28, Dmitry Goncharov wrote: [...] > > $ make -d |tail +7 |head > Reading makefiles... > Reading makefile 'makefile'... > Updating makefiles > Considering target file 'makefile'. > Looking for an implicit rule for 'makefile'. >Trying pattern rule '%: %.o' wi

Re: GNU make troubleshooting

On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > I believe these two user goals are so different; they belong in different > chapters. i believe, a good approach to big debug output is to modify the makefile to relieve make from doing redundant work. Once make only does necessary minimal work

Re: GNU make troubleshooting

Minor side point: the "tail +7" option is deprecated by POSIX, replaced by "tail -n+7". Official GNU documentation should preferably follow POSIX. David On Sat, Jul 15, 2023 at 5:27 PM Bruno Haible wrote: > Dmitry Goncharov wrote: > > > 1) The title, and what does the user want? > > This patch

Re: GNU make troubleshooting

Dmitry Goncharov wrote: > > 1) The title, and what does the user want? > This patch is not a full-fledged troubleshooting guide. ... > > Is that really what I want to do and should do, as a user? > i believe, makefile authors should apply these techniques. OK, then it's appropriate to create *thre

Re: GNU make troubleshooting

> 1) The title, and what does the user want? i guess, users want make to do the minimal amount of work required to fulfil its duties correctly (e.g. track all dependencies, rebuilds, etc). This patch is not a full-fledged troubleshooting guide. This patch describes how to minimize the work that mak

Re: GNU make troubleshooting

Hello Dmitry, Dmitry Goncharov wrote: > >I tried -d a couple of times, and it produced a ton of output, that > >was too much for me to make sense of. Probably 10% to 20% of the > >developers in general have trace filtering skills, that is, know how > >to extract the essential infor

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible wrote: >I tried -d a couple of times, and it produced a ton of output, that >was too much for me to make sense of. Probably 10% to 20% of the >developers in general have trace filtering skills, that is, know how >to extract the essential

Re: GNU make troubleshooting

On Tue, 2023-07-11 at 10:01 -0400, Jeffrey Walton wrote: > > But, what about this do you want to know? > > I want to see an output for the evaluation of each statement, like > what I would see with 'set -x'. I need to know where something goes > sideways when shell'ing out in a pipe. If what you

Re: GNU make troubleshooting

Hi Jeff, On 2023-07-11 16:01, Jeffrey Walton wrote: >> But, what about this do you want to know? > > I want to see an output for the evaluation of each statement, like > what I would see with 'set -x'. I need to know where something goes > sideways when shell'ing out in a pipe. Could you show an

Re: GNU make troubleshooting

On Tue, Jul 11, 2023 at 9:44 AM Paul Smith wrote: > > On Mon, 2023-07-10 at 17:17 -0400, Jeffrey Walton wrote: > > Yes, lots of conditionals and lots of shell'ing, like: > > > > GREP ?= grep > > SED ?= sed > > > > ifneq ($(wildcard /usr/xpg4/bin/grep),) > > GREP := /usr/xpg4/bin/grep > > endif >

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 17:17 -0400, Jeffrey Walton wrote: > Yes, lots of conditionals and lots of shell'ing, like: > > GREP ?= grep > SED ?= sed > > ifneq ($(wildcard /usr/xpg4/bin/grep),) >   GREP := /usr/xpg4/bin/grep > endif > ifneq ($(wildcard /usr/xpg4/bin/sed),) >   SED := /usr/xpg4/bin/sed

Re: GNU make troubleshooting

> From: Bruno Haible > Date: Mon, 10 Jul 2023 21:41:24 +0200 > > Paul Smith wrote: > > Showing the "macroexpanded make sources" is difficult because make > > doesn't just expand an entire line then parse it. Makefile syntax is > > context-sensitive so you can't know how or if to expand parts of

Re: GNU make troubleshooting

> From: Jeffrey Walton > Date: Mon, 10 Jul 2023 16:34:49 -0400 > Cc: bug-make@gnu.org > > I would add GNU's make lacks minimal debug facilities. I think "make -p" and "make -d" do provide ample debugging capabilities. > I think trace is worthless. It does not help the folks writing > makefiles.

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 4:45 PM Paul Smith wrote: > > [...] > > That's like peppering a program with printf's. I would like to > > understand why a statement was (or was not) evaluated, and if > > evaluated the result, but there is no option with the effect of > > Bash's 'set +x'. > > I think I do

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 16:34 -0400, Jeffrey Walton wrote: > I would add GNU's make lacks minimal debug facilities. I assume this is what Bruno means by his point #3: "Single-stepping or tracing function execution". > That's like peppering a program with printf's. I would like to > understand why a

Re: GNU make troubleshooting

Alejandro Colomar wrote: > In GNU Make, the "printf" statement is the > $(info ...) function. Maybe you didn't know about it? Correct, I did not know about it. I created a 'dummy' target with an echo command... It would be really useful to collect all these various troubleshooting tricks in a ch

Re: GNU make troubleshooting

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible wrote: > > In recent build system discussions on gnu-prog-discuss, the suggestion was > made [1] to use GNU make's power instead of autoconf, automake, and POSIX > make. > > I think GNU make is lacking transparency / debuggability / serviceability > fe

Re: GNU make troubleshooting

Hi Bruno, Paul, On 7/10/23 21:41, Bruno Haible wrote: Paul Smith wrote: Showing the "macroexpanded make sources" is difficult because make doesn't just expand an entire line then parse it. Makefile syntax is context-sensitive so you can't know how or if to expand parts of a line until you've a

Re: GNU make troubleshooting

Paul Smith wrote: > > I get the same output with GNU make 4.4 as with 4.3. > > Apologies for my mistake: I'm using the latest release (4.4.1). > I tried your test: > > $ make --trace mbrtoc32.o > Makefile:1752: update target 'mbrtoc32.o' due to: target does not exist With 4.4.1, I see this t

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:41 +0200, Bruno Haible wrote: > > I'm not interested in implementing an "interactive" mode for > > single-stepping GNU Make.  Maybe someone else wants to do it but my > > suspicion is that the code changes needed would be massively > > disruptive. > > That sounds like a di

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:47 +0200, Bruno Haible wrote: > Paul Smith wrote: > > Maybe a version difference.  I'm using 4.4. > > I get the same output with GNU make 4.4 as with 4.3. Apologies for my mistake: I'm using the latest release (4.4.1). I tried your test: $ make --trace mbrtoc32.o Mak

Re: GNU make troubleshooting

Paul Smith wrote: > Maybe a version difference. I'm using 4.4. I get the same output with GNU make 4.4 as with 4.3. Bruno

Re: GNU make troubleshooting

Paul Smith wrote: > Showing the "macroexpanded make sources" is difficult because make > doesn't just expand an entire line then parse it. Makefile syntax is > context-sensitive so you can't know how or if to expand parts of a line > until you've already expanded other parts. Of course make could

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:18 +0200, Bruno Haible wrote: > Paul Smith wrote: > > It's not acceptable (to me) to only show the one newest file, not > > all files that are newer than the target, because often you want to > > know all the newer files. > > You say "It's not acceptable (to me) to only sh

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 21:05 +0200, Bruno Haible wrote: > $ rm -f mbrtoc32.o > $ make --trace mbrtoc32.o If you remove the target then it should only say that it was rebuilt because the target doesn't exist, regardless of how many other prerequisite are out of date, because you can't even compute t

Re: GNU make troubleshooting

Paul Smith wrote: > It's not acceptable (to me) to only show the one newest file, not all > files that are newer than the target, because often you want to know > all the newer files. You say "It's not acceptable (to me) to only show the one newest file", and I say "A tool that shows me 3.7 KB wor

Re: GNU make troubleshooting

On Mon, 2023-07-10 at 20:46 +0200, Bruno Haible wrote: > The " due to: " is useless, since these files > have not changed since the last compilation. (Suggestion: Reduce this > list by showing only the file with the newest timestamp. Files with > older timestamps are redundant.) I can't explain wh

Re: GNU make troubleshooting

I want to prefix this by saying that there's no question that make's traceability could be improved: I'm not saying nothing needs to be done. On Mon, 2023-07-10 at 20:32 +0200, Bruno Haible wrote: > 1) Print the total of the Makefile and all included Makefiles. >    Like what "gcc -E" does with C

Re: GNU make troubleshooting

> 2) Where is the Makefile source for each command that gets executed? >For each command that gets executed, print not only the command (or >nothing if the line begins with '@'), but also the location (which >Makefile, which line number). > >This would help in a number of situation

GNU make troubleshooting

Hi all, In recent build system discussions on gnu-prog-discuss, the suggestion was made [1] to use GNU make's power instead of autoconf, automake, and POSIX make. I think GNU make is lacking transparency / debuggability / serviceability features before this suggestion makes sense. Especially for