Re: Adding debugging to GNU make (Mailing lists are a disaster lately!)

[R. Bernstein]

Eli Zaretskii writes:
 > > Date: Sun, 14 Mar 2004 16:50:53 -0500
 > > From: "Paul D. Smith" <address@hidden>
 > > 
 > > I think a debugger would be cool.
 > 
 > Agreed.
 > 
 > > My one doubt is that it would be overkill.  Do we really need something
 > > this interactive?  

Ummm.... I think I suggested starting off with something more akin to
POSIX shell "set -x" and "set -v" style *tracing*.

 > > Sure, it could be very neat, and there are some very
 > > complex makefiles around but I still have to wonder if overall it's
 > > really needed.  

Clearly something like this viewpoint has contributed to the long-term
neglect of decent debugging in POSIX shells (if not "make") as
well. Actually the parallel runs deeper. Not only neglect of debugging
but just error reporting! Just yesterday I got an error reported from
GNU make: "Error in line 1, mumbledy gook." That error message was in
fact coming from a multi-line shell string, I guess because I was
using an older ksh rather than say bash. Okay that "Line 1"
unhelpfulness is ksh's fault.  But actually not totally -- "make"
could have given me the name and LINE NUMBER in the Makefile from
where the error came from. And/or a traceback.

 > > Maybe the -E-type output would be good enough for the
 > > complex cases that might otherwise use a debugger.
 > 
 > Again, I agree.  I think the -d and -p style output, but one that
 > could be tailored to debugging a specific problem, would be enough.

And again,, think of debugging mechaninsms and paradigms already in
use.  In POSIX shell, not only is ther "set -x" and "set -v", but "set
+v" and "set +x". Perhaps these would add the customization needed.
Although, in truth I'm not a fan of this style of debugging.

 > 
 > For example, it is frequently a case that Make decides not to rebuild
 > a certain target, but it is hard to get it to explain why, because the
 > info printed by -d, even if we put aside its volume, does not really
 > explain itself enough.  It would be cool if Make could say something
 > like ``X has Y as its prerequisite, but Y is older than X, so no need
 > to rebuild X from Y using the rule "frobnicate X -o Y"''.  This might
 > sound trivial when X has only one possible way of being produced, but
 > in a large and complex Makefile, especially in a recursive build,
 > there could be dozens of possible ways of generating X, as "make -d"
 > shows already.  Having all those ways shown explicitly together with
 > Make's decisions spelled in human-readable language would ease the
 > task of debugging Makefile's and Make itself to a large degree, I
 > think.
 > 
 > Similarly, it would be nice to have a way to ask Make to show all the
 > stages of expanding a variable or perhaps all variables used in a
 > certain dependency and the associated rules.

In POSIX shell it's called "set -v", no? 

As for the Paul's comments about how "make" is so unique and special
because it is so functional or it is so hard because the code is
implemented using recursion, akin to LISP -- I'm sorry this is
bullshit.  LISP has had a debugger in fact quite good ones for
probably 30 or more years. And the problems global versus local scope
has also been addressed probably many times too.

I am really delighted to hear that line numbers in make are already
being stored inside the "make" data structures. A pity that they are
used so infrequently. I've never seen them used in "make -d". So then
then implimenting a "make" traceback would be less drastic than I had
originally thought.

Sorry for seeing so bitchy in this note. The complacency coupled with
the neglect for so long touches off a sore nerve. As I said, I wonder
if this kind of thing hasn't also contributed to the lack of debugging
or error reporting in POSIX shells. In fact even now, when you compare
the level of debugging support in BASH using the patched bash from
http://bashdb.sourceforge.net with say Perl or Python or Lisp, you'll
find that there is still quite a bit lacking. But on the other hand,
the task wasn't as unique or difficult as I'm sure some might have
claimed beforehand. 

So let's start moving in the right direction. 

Disclaimer: Not to set expectations too high though, based on bash
work I imagine it will be a year or so before there is something I'm
happy. I started considering debugging for BASH in March 2000 and
dropped it after a couple of months when realizing an incompatible
change to debug handling was needed inside bash. Then I picked it up
again in 2002 and about a year later was able to debug configure
scripts.