Re: GNU make troubleshooting

[Paul Smith]

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 mean is you want to see how the shell itself executes these
commands, make cannot do that because it's the shell that is executing
them not make.  You can edit your $(shell ...) command to add "set -x"
if you like.  Since that goes to stderr it shouldn't interfere with the
behavior of your makefile.

If what you mean is you want to see what the results of expanding the
shell function are as seen by make, then (at least in the cases you've
provided) I already explained that the output of "-p" shows the values
that were assigned and where they came from.

I do agree there's nothing available today which will do something
like, print the results of each line as it was parsed.  If you have
variables that rely on the results of other variables, which might be
later reset to have different values, I understand it can be hard to
figure out if all you have are the final results and not the
intermediate steps.  However the example you provided is not that type
of situation so "make -p" should tell you what you want to know in that
case anyway.

> Here's 'make -d' for a project I help maintain. No info on the
> evaluations shown above, which would be useful to me. There is lots
> of information that looks like it would be useful to a GNU Make
> maintainer.

No.

The -d and --trace options are for users who want to understand why
make is choosing a certain rule, why a given target is being rebuilt,
etc.

In other words, they are describing make's processing _after_ the
makefiles are all parsed and the internal DAG and variable directory is
created.  They are not intended for, nor are they any good for,
understanding how the makefile is parsed and how evaluations are
handled.  You should not try to use them for that, as it will only lead
to frustration.

That doesn't mean that they're useful only for GNU Make maintainers:
there are many situations where users want to understand why some
recipe was invoked, when they didn't think it should be or they thought
some other recipe should be, or why some recipe was NOT invoked (a
target was not rebuilt) when they thought it should be.