[Bashdb-remake] make debugger thoughts

[R. B. <ro...@pa...>]

This is just post some thoughts about the make debugger development.

As I've indicated elsewhere, one interesting but tough thing about
writing this debugger is understanding the user interface. I am not
aware of any other debuggers for Makefiles. What should be shown, ,
what is helpful and what isn't? (Well for one answer to the last
question, I offer GNU's "make -d".)

Lacking input from others, I've pretty much had to rely on my own
experience, which is I guess good since it means that at least the
most annoying things I encounter are fixed (by me) or I just live with
it.

Rather than try to invent a new world, where possible I've been trying
to use familiar debugging and/or language and/or Make concepts. As a
result, there's a target stack and file include stack akin to a stack
trace of a programming language and "where", "backtrace" or "bt", "T" (the
gdb and perldb commands) show this. 

Recently "step" and "next" were separated as they are in other
debuggers. For lack of a better idea, "step" is more fined grained as
it is in other debuggers. Here though is an area where things could
change based on experience.

gdb has "finish" and "return" commands and this is not uncommon among
other debuggers. My current thought is to make "finish" turn off
tracing, stepping/nexting and run until the end of a Makefile. It
seems a little the already existing "continue" (which doesn't turn off
tracing). Another possibility I've toyed with for "finish" are finish
the list of commands in a target, but there generally aren't more than
one command in a target (if that). 

If one continues the analogy between running a makefile with running a
subroutine in a programming language, "return" seems like it would do
the same thing as "quit" currently does - terminate immediately.

I could change "quit" so that it terminates *all* nested invocations
and make "finish" just the last one. In the case that there is only
one Makefile these would do the same thing.

On a different topic, there's always the annoying an pestering problem
of a name. As with bash we need a name for the patched GNU Make -- for
bash before 3.0, it was "rebash", and so for GNU Make it is
"remake". And there's the prompt name used in the debugger which is
generally also the name one would use in GNU Emacs to cause the
debugger to get executed. Following bashdb and perldb and pydb (which
later seems to have become pdb), I chose makedb. However there is
another command called makedb out there to make a DBM file. My current
thought is to rename this mdb to follow, gdb, pdb, jdb, xdb, and
wdb. A google search for mdb doesn't show anything else that's likely
to get confused with this.

And lastly there's the compatibility issue. If this were *completely*
compatible with GNU Make, there wouldn't be any debugger at all ;-) So
there have to be some changes. Largely I've been trying to keep
compatible and add options for more function. So in order to get a
stack trace on error you have to add an option for this -E or
--extended-errors. My current thinking is to make this the default and
possibly have an option to *disable* that behavior. 

Here's another area of incompatibility. In order to make "quit" of
nested makefiles *really* mean quit, the easiest thing to do is to
have this set a special return code, say 77, which is used in
regression tests to indicate a test is to be skipped. Currently GNU
Make never gives this exit code back, but I could be wrong and it is
possible someone out there relies on a 77 return code from a nested
make. In remake what would happen is that remake will see the return
code and terminate with that without as much complaint as it normally
does.