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-prog-discuss] Blog Post Sighting: Autotools Considered Harmful

On Mon, 2023-07-10 at 12:56 -0400, Stefan Monnier wrote: > > There ARE things we could do with GNU Make still that would make it > > more useful, and faster in some situations, without throwing away > > the millions of existing makefiles and the knowledgebase.  I > > maintain a list of them so if t

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

Re: [gnu-prog-discuss] Blog Post Sighting: Autotools Considered Harmful

> There ARE things we could do with GNU Make still that would make it > more useful, and faster in some situations, without throwing away the > millions of existing makefiles and the knowledgebase. I maintain a > list of them so if this kind of works tickles your fancy, or you have > idea of your

[bug #64402] error parsing functions in braces inside ifeq, ifneq

URL: Summary: error parsing functions in braces inside ifeq, ifneq Group: make Submitter: None Submitted: Mon 10 Jul 2023 11:40:55 AM UTC Severity: 3 - Normal It