Re: insufficient debug info from gnu-make

[Edward Welbourne]

> the output I see from make is after all macro substitutions have been  
> made, which can make it virtually impossible
> to recognize as far as where it came from in the original source

This, however, is an issue with how the make file is written.
It sounds like its recipes for commands are of form

target: prerequisites
        $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@

with the various variable expansions coming out horribly long.

You are asking for make to output the above unexpanded line, if I
understand correctly, or at least to have that as one of the forms of
output it can provide.  I suspect you'd be happier yet with something
that would output

Recipe at Makefile:42: $@ = target, $? = prerequisite

or something similar.  You can always look at line number 42 of
Makefile to then find the unexpanded command.  I conjecture that this
might be possible.  Which automatic variables make should report is
open to debate; arguably $@ should be enough, but $? seems like a
reasonable one to also report (it says which prerequisites' newness
forced us to run this recipe).

With things as they stand at present, it is common practice to begin
every recipe with $(QUIET) and have some make-file say
QUIET ?= @
so that one can over-ride it on the command-line, e.g. with QUIET=
to set it empty and get all recipes output in full.  It can be nice to
provide a way to set (definitely using deferred execution)
QUIET = @ echo "Building $@" ;
so as to avoid output of insanely long command-lines yet still get
some indication of what's being built.

As an illustration of the last, I imposed the following standard on
all our make files: I defined a set of make variables with names like
HUSH_<verb> and every recipe had to begin with a suitable one of
these, expanded, so the above would be

target: prerequisites
        $(HUSH_COMPILE) $(CC) $(CFLAGS) $(CPPFLAGS) -c $< -o $@

(In some cases, a rule might begin simply with @ if there is no reason
to ever care about seeing its outut.)  I then have a variable called
LOQUACITY which can take various values (QUIET, TERSE, NORMAL,
DESCRIBE, VERBOSE, DEBUG).  This configures how the HUSH_<verb>
commands are expanded; at some loquacity levels they are @, at some
they're @ echo "<verb>ing $<" ; or @ echo "<verb>ing $@" ; similar to
QUIET (the choice of whether $< or $@ depends on <verb>; compiling $<
but creating $@, for example).  Some verbs cover activities we are
less apt to care about (typically quick intermediate tasks) so are
handled more quietly than others.  (I actually munge $@ or $<, where
used, using a function hush_stem that trims a "boring cruft" prefix
from any file-name, so we typically get source files named relative to
the root of our source tree, rather than relative to the make files,
for example.)

A second variable, SAY_WHY, if set to YES, when LOQUACITY is suitable,
appends
"because of newer $(wordlist 1, 3, $?)$(if $(wordlist 4, 5, $?), ...)"
to what gets echoed, so that you know what changed to make this
necessary (but don't drown users in output if it's many things).

This (along with LOQUACITY ?= NORMAL and SAY_WHY ?= NO) ensures that
normal compilation produces output the developer typically actually
finds useful; but a developer can always quickly (by setting the
relevant variables) gather extra output as needed; or suppress output
they don't care about.  I could probably hack in some use of
$(warning) somewhere in there to cause the output to include the
filename and line number of the recipe being executed - this might be
a viable replacement for echo, making the ; redundant.

The point here is that getting sensible output is a matter of writing
good enough make files, at least for the present.  If you need to
compile stuff from a project that doesn't take good care of its make
files, you're out of luck; make can't really help you all that much.

However, I do see some value in an extension to support command-line
options that would, whenever executing a recipe, output the make-file
name and line number, along with $@ and maybe $? (or at least its
first few entries) - for example --debug=r (recipe) might enable this;
this would fit with the existing --debug options, I think.

        Eddy.