Re: RFC: new debug option "--debug=c" which echoes all commands executed

[R. Bernstein]

Bill Cox writes:
 > R. Bernstein wrote:
 > 
 > I'm interested in what you mean when you say "this kind of tracing"..

Easiest thing is to give an example. Heres a trace from a real project
http://ps-watcher.sourceforge.net.

It is a bit noisy because it uses automake.

% /usr/local/bin/make -x 
/home/src/external-cvs/ps-watcher/Makefile:189 Makefile.in
/home/src/external-cvs/ps-watcher/Makefile:213 config.status
/home/src/external-cvs/ps-watcher/Makefile:216 configure
/home/src/external-cvs/ps-watcher/Makefile:184 all
/home/src/external-cvs/ps-watcher/Makefile:251 all-recursive
/home/src/external-cvs/ps-watcher/Makefile:252 all-recursive
                                               set fnord $MAKEFLAGS; amf=$2; \
dot_seen=no; \
target=`echo all-recursive | sed s/-recursive//`; \
list='docs tests'; for subdir in $list; do \
  echo "Making $target in $subdir"; \
  if test "$subdir" = "."; then \
    dot_seen=yes; \
    local_target="$target-am"; \
  else \
    local_target="$target"; \
  fi; \
  (cd $subdir && /usr/local/bin/make  $local_target) \
   || case "$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac; \
done; \
if test "$dot_seen" = "no"; then \
  /usr/local/bin/make  "$target-am" || exit 1; \
fi; test -z "$fail"
Making all in docs
/home/src/external-cvs/ps-watcher/docs/Makefile:159 Makefile.in[1]
/home/src/external-cvs/ps-watcher/docs/Makefile:181 ../config.status[1]
/home/src/external-cvs/ps-watcher/docs/Makefile:184 ../configure[1]
/home/src/external-cvs/ps-watcher/docs/Makefile:270 all-am[1]
...

I like the fact that there line numbers to indicate where the output
is coming from. And these are in the error line format that is used at
least by emacs (if not other tools) to facilitate automated
positioning the location.

 > And I'll go look at the high-level description that you point at.  I'm
 > wondering if the facilities you're providing are complex.  

If something is done well it shouldn't seem complex. google is complex
but it doesn't seem so. So as I mentioned in a prior post, the trick
is to get the right level of detail. I think as I uses my GNU make
debugger or the "trace" facility of it myself, I become more aware of
what the right level is and how to make it less feel
"complex". Clearly "make -d" is too verbose and not generally
helpful..


 > My proposal
 > isn't at all.  I've done the patch for previous versions of make and
 > the patch was a kilobyte or so, with documentation.

I don't think the size of a patch should be viewed as a sign of
merit. It might mean that it's easier to integrate should it be deemed
useful. But the usefulness should stand on its own.

I guess you are happy with your patch and find it useful, as I find
mine. Great! If you want to offer it to others, that's great too!

Since you originaly asked for comments, there were some I had and
forgot to mention previously.  In adding new features, I often ask
myself if there something that's similar to this that folks may be
familiar with. If so, can I make this look like that rather than
invent new lingo or options?

For example, the command set I'm trying to use in the GNU make
debugger something similar to gdb syntax and/or commands where that
makes sense and is possible. (Right now though the result isn't all
that close even though it is a design goal; for an older project, the
bash debugger it is closer.)  How this relates here was in how I
selected the option name. Above I use the word "trace" since that is
in fact what this sort of does. There is a "trace" mode in the Perl
debugger and POSIX shell has a "trace" mode. So that's how I came up
with the short option -x and long option --trace. And how I thought
this kind of thing might be helpful since it is somewhat familiar.

Happy hacking!