[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Plan for better error reporting, tracing, debugging in GNU make (1st ste

From: R. Bernstein
Subject: Plan for better error reporting, tracing, debugging in GNU make (1st steps)
Date: Sun, 21 Mar 2004 14:08:42 -0500

I've been a bit disappointed with GNU make in its current ability to
help people find and debug problems with Makefiles. I don't see a
particular reason why a debugger for GNU make couldn't ultimately be

So recently I started investigating what it would take to make
progress in better error reporting, tracing and debugging. I've gone
through something like this with a debugger for bash
( And although this project wasn't all
that much fun to do, I've certainly found it very useful. I'm still
surprised it wasn't done earlier.

Although the two projects, bash and make, are probably about the same
age, the code for make 3.80 is much much smaller and overall cleaner
than bash 2.05b. (But as with any project of this age, there is room
for improvement and modernization).

In fact, I was a bit surprised at how much progress I made to the
goal below with very modest effort. A prerequisite to undertaking
such a task is to first add the kinds of support that would be needed
for a debugger.  In particular:

- accurate position information

  Sometimes GNU make reports file/line numbers in dependency tracking,
  but this information not saved during execution of "jobs". It's a
  pretty simple matter to save this.

  The format that should be used would be something that a front-end
  which invokes "make" can use, e.g. the EMACS compilation-next-error()
  routine or a ddd front end.

- call stack information

  Here it would probably mean the stack of target names and parent
  targets for which this was a dependency. (In the code the structure
  for what I call "target" is a "struct file"). With the addition of
  position info above, targets would store file/line number tracing

- execution tracing

  There would probably be something that overrides the @ flag to
  silence commands at the beginning of command execution. You probably
  want this to be more dynamically controlled.

  The places shown in execution tracing would then probably become the
  units for which one would be able to step or set breakpoints in.
  Well, actually it might be a bit more complicated. One might specify
  a target as a breakpoint which would mean *before* dependency
  tracking. So a "next" as opposed to a "step" might mean to skip
  actions taken and rebuilding in doing the dependency checking.
  And then one might envision setting a breakpoint inside a particular
  command of a target.
- showing variable expansion 

  Not much to say here. It's something that is pretty simple to
  do I think for execution tracing. 

- ability to selectively turn on/off these things.

  In addition to a global setting, there would probably a
  trace and variable expansion flag in the target structure. 

Now on to what I've done so far. Basically I've just copied the
file/line info into the target structure and on error I print that.  I
added a "-x" or "--trace" option analogous to -x option in
{,ba,{{t,}c}}sh.  This turns on execution tracing. I also added
"trace", "notrace", "showon" and "showoff" that can be put in the
Makefile which are analogous to the {-,+} {x,v} options on POSIX set.

None of this is flawless, just moving in the right direction.  I
haven't spent all that much effort on this so far.

With these changes, for this simple Makefile in bug2:


while make 3.80 gives this: 

   make: fdafds: Command not found
   make: *** [foo] Error 127

with the simple improvement in reporting errors I get:

   make: fdafds: Command not found
   bug2:2: *** [foo] Error 127

and a "make -x -f bug2" gives this: 

   bug2:2 foo: 
   make: fdafds: Command not found
   bug2:2: *** [foo] Error 127

Not earth shattering, but it's a start. 

- - - - - - 

Lastly, there's a little about working on this. There are some
projects I have to clean off the table to make room for this this
might take a week or so.

I do not consider myself a "make" guru. I'm as (or probably more)
confounded at what automake produces as anyone else. So I really don't
have experience at what the right level of tracing and error reporting
is - yet. Ditto for info that front ends which might call "make" could
better use and how to best serve them in parsing the errors. For
example, should I try to put in the full path in error line? (It seems
that most of the files are called "Makefile", it just the directory
that keeps changing.)

Folks on this list probably are more experienced for such things and
I'd be happy to get suggestions and advice on such things. And if you
want to work on the code that's great too!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]