Re: first GNU make with debugger

[R. Bernstein]

Paul D. Smith writes:
 > When you get to the debugging prompt, what has been done?  

The calls come from update_file() when we are going to push a target
onto the target stack and start_job_command() before starting a new
job. I also considered before popping the target off the stack or
terminating a job. However recently added additional calls are
discussed below.

 > Have all the
 > makefiles been read in already?

I think so, but you're in a better position to answer this than me.

 > 
 > Have you given any thought about how to debug things like $(shell ...)
 > invocations, or eval expansions, etc. that happen during the parsing of
 > the makefiles?

Actually, sort of. I had the idea of a debug-on-error mode. In fact,
I've just hacked in an optional argument on the command line to
--debugger (-X) so you could specify what level of debugging you
want. Right now I have 
   fatal - go into the debugger on a fatal error
   error - go into the debugger on an error or a fatal error
   enter - go into the debugger before any action is taken
   full  - all of the above

So with this, yes, it's possible to enter the debugger on an error in
parsing. For example consider this simple Makefile:

  1: FOO=bar
  2: all: foo
  3: foo:
  4:   @echo hi > /dev/null
     ^^ spaces here

and this debugger session

  ./make --debugger=full -f bug4
  bug4:4: *** missing separator.  Stop.
  (remake) p FOO
  bug4:1 FOO = bar

  (remake) p all

  all: foo
  #  Implicit rule search has not been done.
  #  Modification time never checked.
  #  File has not been updated.

  (remake) where
                       [no call stack]

So here, I guess the variable FOO has been entered into its symbol
table. And so has target "all" even though not much more than
entering has probably been done.

In short, what you get depends on where you've stopped and there isn't
any a priori restriction on that.

This "debugger" (like many others) is merely just a read loop to give
you selective access to the wealth of knowledge that's already inside
the program. Over the weekend I added the ability to show a target's
status. As you probably know, all the hard work was already done in a
routine called "print_file" (which I've renamed "print_target" and
made the trivial change to all it to be externally callable instead of
local only -- thanks for the routine!)

In the past, I used to get either no information, cryptic information
or on the other hand so much spewed out I had a hard time finding the
part that might be interesting. Instead with this, I can ask the
questions I think might be interesting and go on from there.

- - -

I'll close with one other cute unexpected synergy with the bash
debugger. I've often found the shell stuff in Makefiles really hard to
understand with the Make's variables combined in with the shell
variables. With this, I can set a breakpoint on a target with some
code in it, dump out the script part to a file, and then run that in
the bash debugger. And should I chose to fix or patch faulty code on
the fly, I can just continue with make! It might be cool to have some
debugger command automate this: write the script commands of the
current target to a temp file, and then invoke the bash debugger on
that.